Montage Filesystem BTRFS failed

Support Debian
Tags: #<Tag:0x00007f63f50ef348>
#1

Bonjour à tous,

J’ai un système debian 11 qui est sur un fiesystem BTRFS, les données étaient sur du LVM, j’ai décidé de migrer les données sur BTRFS mais lorsque je veux monter les subvolume j’ai l’erreur ci-dessous :

mount: /data: échec de l’appel système mount(2) : Aucun fichier ou dossier de ce type

Ci-dessous les actions que j’ai faites pour ce nouveau système de fichier :

mkfs.btrfs -L btdata /dev/sda1
btrfs subvolume create data
btrfs subvolume create vm
btrfs subvolume create backup

Ci-dessous le contenu de ma fstab :

# <file system>                           <mount point>   <type>  <options>                                <dump>  <pass>
# / was on /dev/sdb2 during installation
UUID=40f6b697-7a4b-4cbc-b1ff-15d03626752b /               btrfs   rw,compress=lzo,space_cache,subvolid=256 0       1
UUID=40f6b697-7a4b-4cbc-b1ff-15d03626752b /home           btrfs   rw,compress=lzo,space_cache,subvolid=257 0       1
UUID=40f6b697-7a4b-4cbc-b1ff-15d03626752b /var            btrfs   rw,compress=lzo,space_cache,subvolid=258 0       1
UUID=40f6b697-7a4b-4cbc-b1ff-15d03626752b /tmp            btrfs   rw,compress=lzo,space_cache,subvolid=259 0       1
UUID=40f6b697-7a4b-4cbc-b1ff-15d03626752b /swap           btrfs   rw,subvolid=260                          0       1
/swap/swapfile                            none            swap    sw                                       0       0                
# /boot/efi was on /dev/sdb1 during installation
UUID=D791-7A2E                            /boot/efi       vfat    umask=0077                               0       1

# btdata

UUID=d7503afe-f650-4814-b3c4-ebbb73a4364e /data           btrfs   rw,compress=lzo,space_cache,subvolid=317 0       1
UUID=d7503afe-f650-4814-b3c4-ebbb73a4364e /vm             btrfs   rw,compress=lzo,space_cache,subvolid=318 0       1
UUID=d7503afe-f650-4814-b3c4-ebbb73a4364e /backup         btrfs   rw,compress=lzo,space_cache,subvolid=319 0       1

Merci pour votre aide.

Willy

#2

uste pour information, tu sais que ce type de fichier a été abandonné par red-Hat; et qu’il utilise un volume d’espace disque plus grand (e crois que la structure de donnée utilise 50% de plus d’espace par rapport au besoin réel de la donnée elle-même)?

Pour ton problème, peux tu essayer le mount avec l’option verbose.

#3

Je n’ai pas vérifié, mais ce n’est pas une erreur que tu peux avoir si le dossier /data n’existe pas ?
Je pose la question parce que tu ne mentionnes pas avoir vérifié son existence, mais c’est probablement pas ça…

#4

uste pour te dire ^^ que RedHat la arrêté le support pour ce recentrer sur le support de XFS depuis 2017, mais que btrfs est toujours maintenu par la communauté, le support sur le kernel 6.2 a même amélioré les performances et seul la gestion du raid5/6 est toujours découragé en production.

Dernière news glané vite fait sur Phoronix Btrfs With Linux 6.2 Bringing Performance Improvements, Better RAID 5/6 Reliability - Phoronix

Source ?

C’est effectivement la première idée, la seconde serait un mauvais subvolid.

#5

Le point de montage existe, il est créé quand tu crées le sous volume avec la commande :
btrfs subvolume create /data.

Willy

#6

Tu confonds le sous-volume et le point de montage.
Quel était le répertoire courant quand tu exécuté les commandes pour créer les sous-volumes ?
Si tu as seulement exécuté ces 4 commandes, alors le système de fichier nouvellement créé n’était pas monté et tu n’a pas pu y créer de sous-volumes, ils ont donc été créés dans le système de fichiers dont un sous-volume contenait le répertoire courant.
Peux-tu lister les sous-volumes de chaque système de fichiers btrfs présent ?

#7

Les 3 nouveaux sous volumes ont été créés dans le répertoire /

root@neptune:/# btrfs subvolume list /
ID 256 gen 110005 top level 5 path @rootfs
ID 257 gen 110013 top level 5 path @home
ID 258 gen 110011 top level 5 path @var
ID 259 gen 110001 top level 5 path @tmp
ID 260 gen 109729 top level 5 path @swap
ID 323 gen 109965 top level 256 path data
ID 324 gen 109997 top level 256 path backup
ID 325 gen 109998 top level 256 path vm

Les 3 nouveaux sous volumes créés sont backup, vm et data.

Willy

#8

Ces trois sous-volumes sont bien dans le système de fichiers racine et ont pour parent le sous-volume @rootfs (subvolid=256) qui est monté sur /. Si tu voulais qu’ils soient dans l’autre système de fichiers, tu t’es loupé. Il fallait monter ce dernier quelque part (temporairement, peu importe où) et créer les sous-volumes avec des chemins dans le point de montage et créer les répertoires qui serviront de points de montage à la racine.

#9

Merci Pascal pour ton aide, j’ai compris mon erreur, j’ai monté le nouveau FS sur /mnt et j’ai créé mes 3 sous volumes et ça fonctionne nickel :slight_smile:

Willy

#10

Assurer la sécurité et la cohérence des données entraîne certes un coût, qu’il faut comparer toutefois avec :

  • D’une part celui d’en avoir moins (coût de la reprise d’activité en cas de catastrophe)
  • D’autre part la baisse du coût du mégaoctet sur disque dur, divisé par 1 300 000 en 29 ans selon Seagate19.

Cela étant rappelé :

  • plus de 50 % du disque sera utilisé essentiellement pour assurer cette sécurité et cette cohérence ;
  • lors de la panne de chaque disque, il faudra démonter le système de fichier ;
  • la fragmentation sera importante, ce qui peut dégrader les performances.
#11

J’utilise BTRFS depuis 5 ans et j’en suis très content, pour information SuSe en a fait sont FS par défaut depuis la SuSe 15. Je sais qu’Oracle continue à pousser pour finaliser le développement du produit. Je connais très bien ZFS, quand BTRFS en aura toutes les fonctionnalités ce sera un outil exceptionnel.

Willy

#12

tout à fait, il devrait effectivement devenir très intéressant

Pour oracle il y a un intérêt évident du fait des fonctionnalité annoncées. la partie espace disque est encore un frein (majeur, d’autant actuellement avec les problèmes d’énergie).