Forum Linux.général [btrfs] Laissez-moi comprendre ces subtilités

Posté par  (site web personnel) . Licence CC By‑SA.
0
29
jan.
2021

J'ai deux machines à la maison qui utilisent btrfs comme système de fichiers. Il y a une Fedora et une Garuda (Arch). Sur ces machines il y a plusieurs disques mais ça OSEF : un de ceux-ci sert de support pour / et home, qui sont en fait des sous-volumes btrfs. Enfin bref, sur la machine A j'ai :

❯ lsblk -f
NAME               FSTYPE      FSVER    LABEL UUID                                   FSAVAIL FSUSE% MOUNTPOINT
sdb
├─sdb1             vfat        FAT32          DBC7-54B8                               298,9M     0% /boot/efi
├─sdb2             btrfs                      1c76a5b8-4879-4bd6-be3a-ce9e49f43444    103,1G    12% /var/log
└─sdb3             xfs                  VM    7e20e932-1297-4039-ba96-cef9f33523b8    119,2G     1% /VM

❯ mount |grep sdb
/dev/sdb2 on / type btrfs (rw,noatime,compress=zstd:3,ssd,space_cache,autodefrag,commit=120,subvolid=256,subvol=/@)
/dev/sdb2 on /srv type btrfs (rw,noatime,compress=zstd:3,ssd,space_cache,autodefrag,commit=120,subvolid=259,subvol=/@srv)
/dev/sdb2 on /root type btrfs (rw,noatime,compress=zstd:3,ssd,space_cache,autodefrag,commit=120,subvolid=258,subvol=/@root)
/dev/sdb2 on /home type btrfs (rw,noatime,compress=zstd:3,ssd,space_cache,autodefrag,commit=120,subvolid=257,subvol=/@home)
/dev/sdb2 on /var/cache type btrfs (rw,noatime,compress=zstd:3,ssd,space_cache,autodefrag,commit=120,subvolid=260,subvol=/@cache)
/dev/sdb2 on /var/tmp type btrfs (rw,noatime,compress=zstd:3,ssd,space_cache,autodefrag,commit=120,subvolid=262,subvol=/@tmp)
/dev/sdb2 on /var/log type btrfs (rw,noatime,compress=zstd:3,ssd,space_cache,autodefrag,commit=120,subvolid=261,subvol=/@log)
/dev/sdb1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
/dev/sdb3 on /VM type xfs (rw,noatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)

et sur la machine B :

 $ lsblk -f
NAME   FSTYPE FSVER LABEL         UUID                                 FSAVAIL FSUSE% MOUNTPOINT
sda
├─sda1 vfat   FAT32 EFI           0476-F8BC                             590,3M     1% /boot/efi
├─sda2 ext2   1.0   BOOT          a561fedc-2474-4cf4-94b8-2e33aa8566ba  699,9M    25% /boot
├─sda3 xfs          VM            f8050f3c-f04c-4ab9-a4b5-9fad508ea22c  248,9G    17% /VM
└─sda4 btrfs        fedora_volume 857c80f3-5dde-4b35-996f-3d2667fa63e1  122,2G    18% /home

 $ mount | grep sda
/dev/sda4 on / type btrfs (rw,noatime,seclabel,compress=zstd:3,ssd,discard=async,space_cache,commit=120,subvolid=257,subvol=/root_sub)
/dev/sda4 on /home type btrfs (rw,noatime,seclabel,compress=zstd:3,ssd,discard=async,space_cache,commit=120,subvolid=256,subvol=/home_sub)
/dev/sda2 on /boot type ext2 (rw,relatime,seclabel)
/dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,errors=remount-ro)
/dev/sda3 on /VM type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota)

où l'on voit bien que /home et / sont montés sur un FS btrfs. Alors oui, on ne vois pas le détail de ce FS, notamment ses sous-volumes, il y a des commandes pour ça (btrfs subvolume list / …), mais là n'est pas la question :

Pourquoi sur un système le point de montage retourné par lsblk est-il /var/log et sur l'autre /home ? Je n'aurais pas été surpris si ça avait été /.


Les /etc/fstab si ça peut être utile :

  • machine A :
❯ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system>                           <mount point>  <type>  <options>  <dump>  <pass>
UUID=DBC7-54B8                            /boot/efi      vfat    umask=0077 0 2
UUID=1c76a5b8-4879-4bd6-be3a-ce9e49f43444 /              btrfs   subvol=@,defaults,noatime,space_cache,autodefrag,compress=zstd,ssd,commit=120       0 1
UUID=1c76a5b8-4879-4bd6-be3a-ce9e49f43444 /home          btrfs   subvol=@home,defaults,noatime,space_cache,autodefrag,compress=zstd,ssd,commit=120   0 2
UUID=1c76a5b8-4879-4bd6-be3a-ce9e49f43444 /root          btrfs   subvol=@root,defaults,noatime,space_cache,autodefrag,compress=zstd,ssd,commit=120   0 2
UUID=1c76a5b8-4879-4bd6-be3a-ce9e49f43444 /srv           btrfs   subvol=@srv,defaults,noatime,space_cache,autodefrag,compress=zstd,ssd,commit=120    0 2
UUID=1c76a5b8-4879-4bd6-be3a-ce9e49f43444 /var/cache     btrfs   subvol=@cache,defaults,noatime,space_cache,autodefrag,compress=zstd,ssd,commit=120  0 2
UUID=1c76a5b8-4879-4bd6-be3a-ce9e49f43444 /var/log       btrfs   subvol=@log,defaults,noatime,space_cache,autodefrag,compress=zstd,ssd,commit=120    0 2
UUID=1c76a5b8-4879-4bd6-be3a-ce9e49f43444 /var/tmp       btrfs   subvol=@tmp,defaults,noatime,space_cache,autodefrag,compress=zstd,ssd,commit=120    0 2
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777  0 0
UUID=4faa31c8-4f9c-4cfc-bdb1-1e3c2c15315d /datas         xfs     defaults,noatime            0 2
UUID=7e20e932-1297-4039-ba96-cef9f33523b8 /VM            xfs     defaults,noatime            0 2

sur la machine B :

 $ cat /etc/fstab

#
# /etc/fstab
# Created by anaconda on Wed Jan 13 17:39:24 2021
#
# Accessible filesystems, by reference, are maintained under '/dev/disk/'.
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
#
# After editing this file, run 'systemctl daemon-reload' to update systemd
# units generated from this file.
#
UUID=a561fedc-2474-4cf4-94b8-2e33aa8566ba   /boot       ext2    defaults                     1 2
UUID=0476-F8BC                              /boot/efi   vfat    umask=0077,shortname=winnt   0 2
UUID=857c80f3-5dde-4b35-996f-3d2667fa63e1   /           btrfs   subvol=root_sub,x-systemd.device-timeout=0,ssd,noatime,space_cache,commit=120,compress=zstd,discard=async              0 0
UUID=857c80f3-5dde-4b35-996f-3d2667fa63e1   /home       btrfs   subvol=home_sub,x-systemd.device-timeout=0,ssd,noatime,space_cache,commit=120,compress=zstd,discard=async              0 0
UUID=f8050f3c-f04c-4ab9-a4b5-9fad508ea22c   /VM         xfs     defaults                     0 0
UUID=665ac575-fbe7-4ad7-9a8d-fc76f3fea6c3   /datas      xfs     defaults                     0 0

Post Scriptum :

  • Je sais et je vois1 que c'est pas facile à lire tout ça, alors n'hésitez pas à copier les partie que ous voulez élucider et ouvrir un nouvel onglet à cette adresse pour y coller le texte : data:text/html, (un bookmarklet à conserver).
  • J'ai suprimé quelques infos non pertinentes, il me semble, concernant les autres disques.

1 : il est tellement facile de vérifier ce que l'on poste en cliquent sur Prévisualiser ;)

  • # le jeu des 7 differences

    Posté par  . Évalué à 1.

    Machine A :
    subvol=@xxxxx

    Machine B :
    subvol=xxxx

    et options de montage

    Machine A : pas de reference à systemd
    Machine B : reference à systemd (x-systemd.device-timeout)

    de là à dire que les versions de btrfs ne sont pas les memes entre les machines

    • [^] # Re: le jeu des 7 differences

      Posté par  (site web personnel) . Évalué à 2.

      Merci Neox.

      Sur les deux machines :

      $ btrfs --version
      btrfs-progs v5.10
      

      même version donc.

      Machine A :
      subvol=@xxxxx

      Machine B :
      subvol=xxxx

      Le subvol=@xxxx est demandé par Timeshift, sinon il ne veut pas faire de snapshot. Voir https://mutschler.eu/linux/install-guides/fedora-btrfs/ :

      a btrfs-inside-luks partition for the root filesystem containing a subvolume @ for / and a subvolume @home for /home. Note that the Fedora installer creates subvolumes root for / and home for /home, so we need to rename these otherwise Timeshift will not work properly.

      « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.