Créer fichier de SWAP sur partition NTFS

Un retour

Comme me l'a suggéré mamiemando (#13), je formate désormais la partition au format SWAP plutôt que gérer par fichier SWAP.

Pour ce faire, j'ai utilisé les déclencheurs (services oneshot) de systemd.

manage_swap.sh

#!/bin/bash

PRT=/dev/sda6

case $1 in
 add)
         mkswap -L "SWAP" $PRT
         swapon $PRT
         ;;
 del)
         swapoff $PRT
         mkfs.ntfs -L "SWAP" -f $PRT &
         pid=$( jobs -p )
         while [[ $( ps xao pid | grep $pid ) ]] ; do true ; done
         ;;      
 *)
         echo "?"
         ;;
esac

chmod +x /data/config/manage_swap.sh

/etc/systemd/system/add_swap.service

Créer le déclencheur au démarrage du système

[Unit]
Description=Add SWAP

[Service]
Type=oneshot
ExecStart=/data/config/manage_swap.sh add

[Install]
WantedBy=multi-user.target

/etc/systemd/system/del_swap.service

Créer le déclencheur avant extinction du système

[Unit]
Description=Del SWAP
DefaultDependencies=no
Before=network.target

[Service]
Type=oneshot
ExecStart=/data/config/manage_swap.sh del

Note 1 : dans le script manage_swap.sh j'ai rencontré une difficulté dans la partie "del" pour m'assurer que le formatage en NTFS soit réellement terminé avant l'extinction finale ; curieusement si on ne le fait pas, la partition de SWAP reste formatée en SWAP Linux et n'est donc pas utilisable sous Windows.

Note 2 : je ne maîtrise pas vraiment l'écriture des fichiers service, je me suis basé sur des exemples que j'ai trouvé ; je pense que ces déclencheurs peuvent être mieux ciblés et optimisés.

J'essayerais de compléter la partie Windows qui doit prévoir que Linux puisse être éteint sauvagement et donc la possibilité que la partition reste formaté en SWAP au boot de Windows qui empêcherait Windows de créer son propre fichier de SWAP.

Bonjour,

Je te recommande de suivre ce tutoriel pour créer de la swap sur un système de fichier arbitraire. C'est d'ailleurs peut être celui que tu as utilisé.

Ensuite, je ne pense pas que l'étape avec dd soit indispensable. Cette étape sert juste à écraser toute trace des données présentes sur cet espace disque. Mais en réalité, les zones concernées n'ont pas besoin d'être réinitialisées à 0 pour être utilisables.

À tester, mais concernant ntfsfallocate, je pense qu'il faut :

1. Monter la partition (disons dans /media/windows)
2. Créer le fichier vide
3. Démonter la partition
4. Utiliser ntfsfallocate, car maintenant, le fichier cible a un inode dans le système de fichiers NTFS

Attention : Prends le temps de comprendre chaque commande, de t'assurer de savoir ce que tu fais, et de vérifier que les paramètres sont bien les bons dans ton cas de figure, car sinon tu risques d'écraser des données de manières irréversibles !). Une fois cet avertissement pris en compte, voici à quoi ça devrait ressembler :

sudo mkdir -p /media/windows
sudo mount /dev/sda6 /media/windows
sudo mkdir /media/windows/swap
sudo touch /media/windows/swap/swapfile
sudo umount /media/windows
sudo ntfsfallocate -l 8G /dev/sda6 swap/swapfile
sudo mount /dev/sda6 /media/windows
sudo dd if=/dev/null of=/media/windows/swap/swapfile bs=100M
ls -sh /media/windows/swap/swapfile

Remarque : Le paramètre bs de la commande dd permet d'accélérer la vitesse (après il faut que le disque suive). Plus de détails sur cette discussion.

Bonne chance

Bonjour,

Précisions sur les comportements de truncate et ntfsfallocate :

En cas d'augmentation importante de taille, ces deux commandes créent un trou en fin de fichier ("sparse file"). Ce trou apparaît comme une suite de zéros qui n'existent pas sur disque. Toutefois ntfsfallocate alloue et réserve l'espace du trou, alors que truncate ne le réserve pas.

Dans le cas de ntfsfallocate, lorsqu'on écrit dans le trou, l'espace entre l'ancienne fin de fichier, et le début de la nouvelle zone d'écriture est réellement mis à zéro, ce qui n'est pas le cas après truncate. Cela a un effet sur la durée des premières écritures après ntfsfallocate, et on peut forcer une réelle mise à zéro initiale du trou en allongeant le fichier (du genre echo X >> /media/windows/swap/swapfile).

> Quand on utilise ces commandes il y a nécessairement augmentation, non ?

Oui, mais cela ne veut pas dire qu'un espace a été réservé sur disque. Les systèmes de fichier peuvent donner l'impression qu'il y a des zéros sans pour autant mettre ces zéros quelque part sur disque. C'est qu'on appelle un trou (hole), le fichier devient alors un "sparse file".

Comme je le comprend, c'est dans les méta-données (tables du système de fichiers ?) qu'il y a un mécanisme qui évite d'avoir à physiquement.

Oui, et dans ce cas l'allocation (c'est-à-dire l'attribution d'un espace sur le disque) n'est faite qu'en cas d'écriture dans le trou. Le trou est alors partiellement bouché, mais il peut rester des trous des deux côtés de l'espace qui est alors réservé.

fallocate et ntfsfallocate font des trous spéciaux qui sont réservés sur disque, mais dont les zéros ne sont pas écrits. Ces trous spéciaux ne peuvent exister qu'en fin de fichier.

Exemples (je ne l'ai pas testé). Noter que les zones allouées se font par clusters entiers (souvent 4096 octets).

1) création d'un fichier presque vide :

echo > fichier

A ce stade "du fichier" donne une petite valeur (par exemple 4) car un seul bloc a été alloué

2) allongement à 64k, sans allouer d'espace complémentaire

truncate -s 65536 fichier

A ce stade "du fichier" donne encre une petite valeur car peu de blocs supplémentaire n'ont été alloués, mais le fichier donne l'impression de contenir 65536 octets. Il peut y avoir un changement de représentation du fichier conduisant à une petite allocation complémentaire.

3) écriture de azerty au milieu du trou :

echo azerty | dd of=fichier bs=1024 seek=32 conv=notrunc count=1

A ce stade le fichier a un peu d'espace alloué au début et au milieu avec des trous entre les deux zones et à la fin. "du fichier" va donc encore augmenter un peu.

4) réservation d'espace en fin de fichier :

fallocate -o 65536 -l 65536 fichier

Au-delà de l'espace antérieur (avec deux trous), 65536 octets ont été réservés et donnent l'impression de contenir des zéros. Comme cet espace est réservé, la valeur de "du fichier" augmente de 64. Toutefois ces zéros n'ont pas été écrits.

5) écriture au-delà du trou en fin de fichier

echo X >> fichier

Comme l'espace du trou final a été réservé, le système de fichiers est cette fois obligé de mettre la totalité de ce trou à zéro. Ce n'est pas le cas des deux premiers trous, car ils n'ont pas été réservés.

NB ntfsfallocate fonctionne à peu près comme fallocate, mais il est spécifique aux fichiers sur partition ntfs non montés.

NB2 ne pas confondre une partition swap avec un fichier swap. La commande mkfs.ntfs crée une partition ntfs, pas une partition (ou un fichier) de swap.

@swap

Merci pour les éclaircissements.

Je vais étudier et tester précisément ce que tu dis ici (je me rends compte que j'ai des lacunes sur le sujet), mais si je lis entre les lignes ce que tu ne dis pas franchement, c'est que ce que je veux faire c'est impossible puisqu'il faut que la zone soit complètement allouée, donc remplie de zéros, donc passer par dd (ce qui rallongerait drastiquement le temps de démarrage).

Q1 : C'est bien ça ? Sinon comment ferais-tu pour créer un fichier de swap SANS trous sans passer par dd ?

Dans le commentaire #7 je teste le formatage de la partition (le formatage rapide ou complet donne le même résultat) avant d'utiliser truncate. En toute logique le système de fichier de la partition a tout l'espace disponible, donc pas de fragmentation possible et pourtant le fichier créé a quand même des trous.

Q2 : Comment ça se fait ?

Excuses-moi d'insister mais :

Q3 : Si le système de fichiers sait qu'un programme a besoin d'un espace continu de A à B, s'il n'a pas à gérer une quelconque fragmentation, qu'est ce qui l'empêche de le faire sans avoir à physiquement remplir cet espace de zéros ?

J'ai l'impression que dans mon cas, dd fait des choses en trop de ce qu'il devrait faire (et ça se traduit par une perte de temps). Un peu comme le formatage rapide et complet : le "rapide" prend quelques secondes car il y a juste à modifier les méta-données dans le système de fichiers, le "complet" prend tout le temps nécessaire pour remplir de zéros chaque blocs du disque (je peux me tromper de cible).

NB ntfsfallocate fonctionne à peu près comme fallocate, mais il est spécifique aux fichiers sur partition ntfs non montés.

Q4 : Tu sais pourquoi l'outil ntfsfallocate fonctionne hors montage (je trouve ce mécanisme aberrant) ?

NB2 ne pas confondre une partition swap avec un fichier swap. La commande mkfs.ntfs crée une partition ntfs, pas une partition (ou un fichier) de swap.

Il y a méprise, je ne veux pas créer de partition de swap mais une partition qui contienne un fichier de swap (formaté avec mkswap) et ce pour pouvoir partager cet espace entre systèmes dans un multiboot et gagner de la place (voir mon 1er post).