Republication d'article : source

Revu sommaire du système de fichiers “BTRFS” .

Comme souvent, je rédige ce post au fur et a mesure de mes découvertes: il ne s’agit pas d’un cours et les erreurs ne sont pas exclus.

Je ne parlerai pas des propriétés d’agrégation de disques pour constituer des RAIDs: c’est un vaste sujet qui ne m’intéresse pas ici.

Si nécessaire, il faut installer la suite logiciels de base (Ici, pour “Debian Stretch”):

# apt-get install btrfs-progs

Avec “Debian Jessie”, le package est nommé “btrfs-tools”.

A partir d’une partition vide, on peut simplement formater:

# mkfs.btrfs <device>

Maintenant , on va monter ce système de fichier et modifiant le fichier “/etc/fstab”.

Le montage sera fait dans “/mnt/data”.

Et pour les points de montage, je préfère créé des dossiers sans (trop de) permission:

# mkdir -m 0000 /mnt/data

La méthode classique :

Exemple, dans « /etc/fstab » :

/dev/xvdb1      /mnt/data       btrfs   defaults    0       0

La méthode avec “UUID” :

# btrfs fi show <device>
... uuid: xxxxxx
...

Récuperer l’UUID et puis dans « /etc/fstab » :

UUID=xxxxxx     /mnt/data       btrfs   defaults    0       0

Maintenant, on peut monter comme un chef:

# mount /mnt/data

Avec “systemd” , on peut aussi faire, après la modification du fichier “/etc/fstab” :

# systemctl daemon-reload
# systemctl start /mnt/data

Si on veut de la compression, en voila.

Ajouter dans /etc/fstab :

/dev/xvdb1      /mnt/data       btrfs   defaults,compress=lzo    0       0

et puis:

# umount /mnt/data
# mount /mnt/data

ou mieux (?):

# systemctl daemon-reload
# systemctl reload /mnt/data

Forcer la compression des fichiers existants (tous ne seront pas forcement compressé… voir “–compress-force” pour ça. )

# btrfs filesystem defragment -clzo <mountpoint>

# btrfs filesystem df <mountpoint>
Data: total=200.00GB, used=68.59GB
System: total=32.00MB, used=20.00KB
Metadata: total=99.97GB, used=34.27GB
# df -h <mountpoint>
Sys. fich.     Taille Util. Dispo Uti% Monté sur
<device>         300G  103G  132G  44% <mountpoint>
subvolume
# btrfs subvolume create /mnt/data/SUBVOL-0001

… etc…

# btrfs subvolume list <mountpoint>
ID 402 top level 5 path SUBVOL-0001
ID 403 top level 5 path SUBVOL-0002
ID 404 top level 5 path SUBVOL-0003
ID 405 top level 5 path SUBVOL-0004
...

(une extension des “subvolume”)

# btrfs subvolume snapshot -r <mountpoint> <mountpoint>/SNAPSHOT-0001

-r le snapshot est créé en “read-only”

# btrfs subvolume delete <mountpoint>/SNAPSHOT-0001

Imaginons qu’un malotru efface toutes les données par un:

# rm -Rf /mnt/data/*

Si on a un snapshot ici « /mnt/data/SNAPSHOT-0001 » , par exemple, la meilleure manière de restaurer est:

# cp -ax --reflink=always -T /mnt/data/SNAPSHOT-0001/ /mnt/data/

“–reflink=always” va juste créer des meta-données (nom du fichier+quelques infos) et puis surtout: faire pointer les données sur les mêmes que le “snapshot” !

Donc: copie très rapide, et pas de données en double. ❗ Cela ne fonctionne que parce que le disque physique est le même, et que « BTRFS » supporte cette “magie”.

Il y a un “certain” décalage entre le moment où les données sont écrites et le moment où elles sont pris en compte dans l’occupation d’un espace disque, via la commande “df” par exemple.

Pour synchroniser rapidement le véritable état d’une partition:

# btrfs filesystem sync <mountpoint>

En supposant qu’on est sur une image « LVM » (ce qui est le cas le plus simple).

# btrfs filesystem show /mnt/btrfs2
Label: none  uuid: 2d3ea2cd-efe0-4acb-8cc2-2b418329e06e
        Total devices 1 FS bytes used 128.00KiB
        devid    1 size 1.00GiB used 138.38MiB path /dev/mapper/vg0-btrfs2
 
Btrfs v3.17

LVM:

# lvresize -L +1G /dev/vg0/btrfs2 
  Size of logical volume vg0/btrfs2 changed from 1,00 GiB (256 extents) to 2,00 GiB (512 extents).
  Logical volume btrfs2 successfully resized

File System:

# btrfs filesystem resize max /mnt/btrfs2
Resize '/mnt/btrfs2' of 'max'

Voila:

# btrfs filesystem show /mnt/btrfs2
Label: none  uuid: 2d3ea2cd-efe0-4acb-8cc2-2b418329e06e
        Total devices 1 FS bytes used 128.00KiB
        devid    1 size 2.00GiB used 138.38MiB path /dev/mapper/vg0-btrfs2
 
Btrfs v3.17
# df -h /mnt/btrfs2
Sys. de fichiers       Taille Utilisé Dispo Uti% Monté sur
/dev/mapper/vg0-btrfs2   2,0G    256K  1,9G   1% /mnt/btrfs2

❗ La bonne taille est celle affiché par “btrfs filesystem show <device>”

# btrfs filesystem show /mnt/btrfs2
Label: none  uuid: 2d3ea2cd-efe0-4acb-8cc2-2b418329e06e
        Total devices 1 FS bytes used 128.00KiB
        devid    1 size 2.00GiB used 138.38MiB path /dev/mapper/vg0-btrfs2
 
Btrfs v3.17
# btrfs filesystem resize 900M /mnt/btrfs2
Resize '/mnt/btrfs2' of '900M'
# lvresize -L 1000M /dev/vgO/btrfs2
...
  Size of logical volume vg0/btrfs2 changed from 2,00 GiB (512 extents) to 1000,00 MiB (250 extents).
  Logical volume btrfs2 successfully resized
# btrfs filesystem resize max /mnt/btrfs2
Resize '/mnt/btrfs2' of 'max'

Voila:

# btrfs filesystem show /mnt/btrfs2
Label: none  uuid: 2d3ea2cd-efe0-4acb-8cc2-2b418329e06e
        Total devices 1 FS bytes used 128.00KiB
        devid    1 size 1000.00MiB used 138.38MiB path /dev/mapper/vg0-btrfs2
 
Btrfs v3.17

Lorsque tout les « chunks » “Btrfs” sont tous alloués, ça craint.

Lorsqu’on a fait de la place sur une partition, il peut être suffisant de “balancer” un peu la partition pour que les « chunks » se libèrent… (a priori, c’est automatique depuis « Debian Stretch »).

# btrfs balance start -dusage=0 <montage_btrfs>

Exemple:

# btrfs fi show /dev/vg1/monster-project
Label: none  uuid: 11fe06a4-4249-4eaa-ad2a-3975940ba060
        Total devices 1 FS bytes used 436.33GiB
        devid    1 size 2.64TiB used 2.64TiB path /dev/mapper/vg1-monster--project
 
Btrfs v3.17

On balance:

# btrfs fi balance start -dusage=0 /mnt/monster-project

Et puis attendre, ou suivre sur une autre console:

# btrfs fi balance status /mnt/monster-project
Balance on '/mnt/monster-project/' is running                                                                           
987 out of about 1594 chunks balanced (1231 considered),  38% left 

(aparté)

Forcer linux a recharger les partitions:

# partprobe <DEVICE>

L’un des “petits” problèmes de « Btrfs », sur des disques de plusieurs Téra (au moins 10T , pour moi), le montage d’une partition peut être très long, bien au delà de la limite par défaut de “systemd”, soit 90 secondes.

(J’ai lu qu’un disque de plus de 40T pouvait mettre jusqu’à 4 heures a monter! c’est flippant!)

Pour commencer, il faut trouver un autre biais pour monter les disques sans que le boot soit bloqué !!! : Dans “/etc/fstab” , on sera bien heureux d’ajouter a ces options de montage:

noauto,x-systemd.automount

Ça dit:

En pratique, “noauto” sera contredit pas “x-systemd.automount”, parce que cette option exige le montage de la partition dés que possible : dans le meilleur des cas, au boot, mais pas obligatoirement.

Sur des énormes partitions, il faut modifier le “timeout” de temps de montage.

Pour cela, il suffit d’ajouter dans les options de montage “/etc/fstab”:

x-systemd.mount-timeout=<TIMEOUT>

Remplacer “<TIMEOUT>” par le temps d’attente maximum. Par exemple, pour 10 minutes, c’est simplement: “10m”

Exemple d’une ligne complète:

/dev/sdd1      /mnt/fuck-hadopi            btrfs   defaults,compress=lzo,commit=10,noauto,x-systemd.automount,x-systemd.mount-timeout=10m    0       0

Pour avoir une idée des montages (et autres) qui sont long a mettre en service au « boot » par « systemd » :

# systemd-analyze blame

Sources:

• https://github.com/systemd/systemd/issues/4055
• https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#systemd-auto-mounts-incompat

Si les accès disques sont très lent, peut être a cause de la “compression”, alors la mémoire cache destiné aux accès disques peut augmenter excessivement et “oom_killer” peut se réveiller et “killer” des process…

Hummm… relou.

La solution, surtout si vous avez une carte RAID dédié avec de la RAM, c’est de libérer au plus vite cette mémoire.

Si j’ai bien compris, cette mémoire s’appelle la “dirty memory”.

Dans “/etc/sysctl.d/local.conf”:

vm.dirty_background_ratio = 1                                                                                                                    
vm.dirty_ratio = 10

# sysctl -p local.conf

Source: https://lonesysadmin.net/2013/12/22/better-linux-disk-caching-performance-vm-dirty_ratio/

Sans RAID en place.

La ligne “/etc/fstab” concernant ce montage disque:

/dev/vg0/smb_super-gestion   /mnt/super-gestion        btrfs   rw,acl,noexec,noauto,x-systemd.automount        0       0

# btrfs fi show /mnt/super-gestion/
Label: none  uuid: 0e077ef7-4170-4d62-bd53-4630b1359c1b
        Total devices 1 FS bytes used 1.01TiB
        devid    1 size 1.20TiB used 1.01TiB path /dev/mapper/vg0-smb_super--gestion

On a un disque de taille identique (ou plus grand) de prêt…

On ajoute ce disque:

# btrfs device add /dev/vg1/smb_super-gestion /mnt/super-gestion
# btrfs fi show /mnt/super-gestion/
Label: none  uuid: 0e077ef7-4170-4d62-bd53-4630b1359c1b
        Total devices 2 FS bytes used 1.01TiB
        devid    1 size 1.20TiB used 1.01TiB path /dev/mapper/vg0-smb_super--gestion
        devid    2 size 1.20TiB used 0.00B path /dev/mapper/vg1-smb_super--gestion

❗ ATTENTION: faire l’opération suivante dans une console “tmux” ou “screen”: ce traitement peut durer des heures !!!

On retire le disque précédent, et hop, une copie intégrale s’opère …

# btrfs device delete /dev/vg0/smb_super-gestion /mnt/super-gestion

… quelques heures plus tard la commande est terminée.

# btrfs fi show /mnt/super-gestion/
Label: none  uuid: 0e077ef7-4170-4d62-bd53-4630b1359c1b
        Total devices 1 FS bytes used 1.01TiB
        devid    2 size 1.20TiB used 1.01TiB path /dev/mapper/vg1-smb_super--gestion

On termine en adaptant le fichier “/etc/fstab” en faisant référence au nouveau disque:

/dev/vg1/smb_super-gestion   /mnt/super-gestion        btrfs   rw,acl,noexec,noauto,x-systemd.automount        0       0

Et puis on recharge la nouvelle configuration:

# systemctl daemon-reload
# systemctl reload /mnt/super-gestion

Et voila, on a transféré un disque complet sans interruption de service.

Sources:

• http://www.funtoo.org/BTRFS_Fun#Using_snapshots_for_system_recovery_.28aka_Back_to_the_Future.29
• https://www.howtoforge.com/a-beginners-guide-to-btrfs
• http://www.oracle.com/technetwork/articles/servers-storage-admin/advanced-btrfs-1734952.html
• http://journaldunadminlinux.fr/presentation-de-btrfs-et-comment-migrer/