Système de fichiers BTRFS multi-périphérique avec disque de taille différente

J'ai un système de fichiers BTRFS existant composé d'un disque de 500 Go et je viens d'acheter un disque de 2 To pour augmenter la capacité de stockage de mon serveur domestique et je veux ajouter le nouveau disque au système de fichiers existant. D'après ce que j'ai lu, il semble qu'aucune configuration BTRFS ne puisse gérer un disque de tailles différentes sans gaspiller la différence de taille entre le disque plus grand et le plus petit, mais je suis nouveau sur BTRFS et j'ai peut-être manqué quelque chose, donc y a-t-il une configuration qui peut me permettre de combiner deux disques dans un système de fichiers sans gaspiller d'espace?

Btrfs peut utiliser différents niveaux de raid pour les données et les métadonnées:

la valeur par défaut (même pour un disque) est raid1 pour les métadonnées (répertoires, etc.) et raid0 pour les données.

Si vous n'avez pas changé cela, vous n'aurez probablement aucun problème à ajouter le deuxième disque et à rééquilibrer. car seules les métadonnées seront copiées sur les deux disques (vous pouvez voir la taille de vos métadonnées avec btrfs filesystem df /). Sachez simplement que si l'un de vos disques tombe en panne, vous perdez des données.

parce que le disque de 2 To est tellement plus gros que le 500 g, cela vous donnerait peut-être de meilleures chances si vous ajoutez le nouveau et retirez l'ancien (les chances de défaillance d'un lecteur spécifique sont bien inférieures aux chances de l'un des lecteurs) échouer).

si vous prévoyez d'avoir un ensemble RAID plus tard (avec des disques de taille plus similaire), vous voudrez peut-être recréer le système de fichiers sur le nouveau disque avec raid1 pour les données et les métadonnées, puis tout copier. puis plus tard, lorsque vous aurez plus d'argent, achetez le deuxième lecteur de 2 To.

ps: l'utilisation de raid1 sur un seul lecteur signifie que les données seront stockées à deux endroits sur ce même lecteur (pour se protéger contre la corruption) et réduiront votre espace de stockage (c'est vraiment une très bonne idée pour les métadonnées).

pss: sérieusement, ne soyez pas tenté de ne pas utiliser raid1 pour les métadonnées. psss: il y a de très bonnes chances que btrfs gagne la possibilité de changer dynamiquement les niveaux de raid.

Cela dépend du profil que vous utilisez pour les blocs de données du système de fichiers Btrfs multi-périphérique.

• Lorsque vous utilisez RAID0 (la valeur par défaut pour les blocs de données), chaque disque ne peut être rempli qu'à la capacité du plus petit disque de la baie.

• Lorsque vous utilisez le profil "unique" pour les blocs de données, chaque disque sera rempli à sa pleine capacité. par exemplemkfs.btrfs -d single /dev/sda /dev/sdb

J'ai un serveur de fichiers avec un disque de 2 To et un disque de 3 To. Il démarre Ubuntu 12.10 à partir d'une clé USB. J'ai d'abord créé le système de fichiers Btrfs sans l' -d singleoption:

mkfs.btrfs /dev/sda /dev/sdb

Le résultat était que je ne pouvais stocker qu'environ 4 To (3,45 données de fichier binaire TB).

# btrfs fi show
Label: none  uuid: 3a63a407-dd3c-46b6-8902-ede4b2b79465
 Total devices 2 FS bytes used 3.22TB
 devid    2 size 2.73TB used 1.82TB path /dev/sdb
 devid    1 size 1.82TB used 1.82TB path /dev/sda
# btrfs fi df /mnt/btrfs1/
Data, RAID0: total=3.45TB, used=3.22TB
Data: total=8.00MB, used=0.00
System, RAID1: total=8.00MB, used=264.00KB
System: total=4.00MB, used=0.00
Metadata, RAID1: total=94.00GB, used=4.29GB
Metadata: total=8.00MB, used=0.00
# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb        4.6T  3.3T  241G  94% /mnt/btrfs1

Notez le used 1.82TBpour le lecteur de 3 To.

Ensuite, j'ai utilisé la commande "balance" pour convertir les blocs de données de RAID0 en profil "unique":

btrfs balance start -dconvert=single /mnt/btrfs1

Il a fallu beaucoup de temps (environ 30 heures) pour équilibrer les données de 4 To. Mais une fois terminé, j'ai pu utiliser la totalité des 5 To (données de fichier binaire de 4,36 To).

# btrfs fi show
Label: none  uuid: 3a63a407-dd3c-46b6-8902-ede4b2b79465
 Total devices 2 FS bytes used 4.34TB
 devid    2 size 2.73TB used 2.73TB path /dev/sdb
 devid    1 size 1.82TB used 1.82TB path /dev/sda
# btrfs fi df /mnt/btrfs1/
Data: total=4.36TB, used=4.34TB
System, RAID1: total=40.00MB, used=500.00KB
System: total=4.00MB, used=0.00
Metadata, RAID1: total=94.00GB, used=4.01GB
Metadata: total=8.00MB, used=0.00
# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb        4.6T  4.4T   27G 100% /mnt/btrfs1

J'ai utilisé plusieurs appareils avec btrfs dans Ubuntu, et cela a très bien fonctionné. Gardez à l'esprit que btrfs n'implémente pas réellement les niveaux RAID standard. Il implémente le striping et la mise en miroir optionnels, mais pas le vrai RAID.

Il est possible de combiner des disques de différentes tailles dans btrfs.
Mais actuellement, btrfs ne gère pas très bien ENOSPC (pas d'espace disponible sur l'appareil).

Par exemple, j'ai installé 3 disques dans une matrice RAID0 (rayée). 1x500 Go, 1x250 Go, 1x160 Go.
Vous supposeriez que vous disposerez d'un espace disque compris entre 800 et 900 Go.

C'est ce que df -hmontre:
/ dev / sdf 848G 615G 234G 73% / media / btrfs

Mais je ne peux plus stocker de données sur la baie. (Pas d'espace disponible)

btrfs filesystem df /media/btrfsme montre ceci:
Données: total = 612,51 Go, utilisé = 612,51 Go
Métadonnées: total = 1,62 Go, utilisé = 990,73 Mo
Système: total = 12,00 Mo, utilisé = 48,00 Ko

Même le rééquilibrage n'a pas aidé.

Sur une liste de diffusion, j'ai vu ce calcul:
taille du plus petit disque * nombre de disques dans la matrice
(bien que j'ai plus d'espace: 612 Go au lieu de 160 Go * 3 = 480 Go)

Donc, dans l'état actuel de développement, il est probable que vous ne pourrez pas utiliser tout l'espace dont vous disposez, même si btrfs prend en charge différentes tailles dans un même tableau.

J'utilise Ubuntu 10.10 avec un noyau générique 2.6.35-22.

mise à jour: la réponse ci-dessous a été écrite avant la sortie de Linux 3.0. Linux 3.0 inclut le patch quasi-round-robin.

Lorsque vous effectuez une mise en miroir ou une répartition des données, le deuxième miroir ou segment de bande doit être alloué sur un autre appareil disposant d'espace libre. BTRFS alloue des morceaux aux appareils de manière circulaire, ce qui peut entraîner une perte d'espace si vous avez des appareils de tailles différentes.

Il y a un correctif quasi-circulaire dans le pipeline pour améliorer cela. Bien sûr, il est toujours impossible de coupler tous les morceaux sur différents appareils si vous disposez d'un disque de 500 Go et de 2 To. Le correctif est plus destiné à des situations comme 1 x 1 To + 2 x 500 Go où chaque petit disque devrait préférer refléter / agréger avec le gros disque au lieu de l'autre petit disque.

Dans votre situation, je voudrais simplement utiliser le mode "unique" pour vos données ( mkfs.btrfs -d single). Les morceaux ne sont pas couplés dans ce mode, donc je pense qu'il n'y aurait aucun problème avec des appareils de différentes tailles. Je ne l'ai pas testé cependant.

Ce problème ne s'applique qu'aux configurations btrfs-raid1, à partir de la page Gotchas :

• L'allocation se fait sur une base de tournoi à la ronde. Si vous avez une stratégie raid1 sur un volume composé de disques incompatibles (volumes de tailles différentes), votre plus petit volume peut se remplir tout en laissant beaucoup d'espace libre sur votre plus gros disque. Vous pouvez vérifier qu'il s'agit d'un problème en cas de divergence entre 'df' et 'btrfs filesystem df [mountpoint]' ET si cette dernière commande montre également que "total" et "used" sont les mêmes sur la ligne "Data" . Un rééquilibrage peut atténuer ce problème. (2.6.33)
  • Si votre volume se remplit de cette manière, un rééquilibrage peut rapidement provoquer un ENOSPC ("Erreur NO SPaCe laissé sur l'appareil") oups. Vous devrez peut-être supprimer un fichier relativement volumineux pour résoudre cette impasse, puis un rééquilibrage réussira. (2.6.33)
  • Le rééquilibrage peut entraîner une utilisation rapide et intense du processeur pendant de longues périodes. (2.6.34 et 2.6.35)