Ext4 vs. XFS vs. Btrfs vs. ZFS pour NAS

Je utilise généralement l'un des deux systèmes de fichiers suivants :

• XFS pour tout ce qui ne fonctionne pas bien avec CoW (ou pour les machines virtuelles dont le datastore se trouve déjà sur un système de fichiers CoW) ou lorsque une E/S directe extrêmement rapide est requise;

• ZFS pour tout le reste.

Pour votre cas d'utilisation, je utiliserais ZFS, en particulier compte tenu que Ubuntu 18.04 le fournit déjà. Comme vous pouvez facilement attacher une autre branche de miroir à un périphérique existant, ZFS convient très bien. Par exemple, nommons votre disque nvme0p1:

• zpool create tank /dev/nvme0p1 crée votre pool vdev unique appelé "tank";
• zpool attach tank /dev/nvme0p1 active la mise en miroir.

Si, pour certaines raisons, vous ne pouvez pas / ne voulez pas utiliser ZFS, alors MDRAID et XFS sont vos amis :

• mdadm --create /dev/md200 -l raid1 -n 2 /dev/nvme0p1 missing créera un ensemble RAID1 avec une branche manquante (voir #1);
• mdadm --manage /dev/md200 --add attache une nouvelle branche miroir (formant un RAID1 complet, voir #2)

Après avoir créé le tableau, vous pouvez le formater avec XFS via mkfs.xfs

Je ne recommande pas d'utiliser BTRFS, car à la fois les performances et la résilience sont médiocres. Par exemple, du wiki de Debian :

Il y a actuellement (2019-07-07, linux 5.1.16) un bug qui fait qu'un profil RAID1 à deux disques devient en lecture seule à jamais la deuxième fois qu'il est monté dans un état dégradé - par exemple en raison d'un disque manquant/cassé / réinitialisation du lien SATA

Veuillez également noter que les fournisseurs commerciaux de NAS utilisant BTRFS (à savoir Synology) n'utilisent pas leur propre fonctionnalité RAID intégrée; plutôt, ils utilisent la couche prouvée Linux MDRAID.

ÉDIT : alors que certains affirment que XFS est sujet à des pertes de données, ce n'est tout simplement pas correct. Eh bien, par rapport à ext3, XFS (et d'autres systèmes de fichiers prenant en charge une allocation différée) peuvent perdre plus de données non synchronisées en cas d'extinction non contrôlée. Mais les données synchronisées (c'est-à-dire les écritures importantes) sont à 100% sécurisées. De plus, un bug spécifique exacerbant la perte de données XFS a été corrigé il y a plus de 10 ans. Mis à part ce bug, n'importe quel système de fichiers prêt pour une allocation différée (y compris ext4 et btrfs) perdra un nombre important de données non synchronisées en cas d'extinction non contrôlée.

Par rapport à ext4, XFS offre une allocation illimitée de numéro d'inode, un support d'indices avancé (si vous en avez besoin) et, dans les versions récentes, le support de lien reflété (mais ils doivent être explicitement activés dans Ubuntu 18.04, voir la page man de mkfs.xfs pour plus d'informations)

1: Exemple de fichier /proc/mdstat avec un périphérique manquant:

Personalities : [raid1]
md200 : active raid1 loop0[0]
      65408 blocs super 1.2 [2/1] [U_]

dispositifs inutilisés : 

2: Fichier /proc/mdstat après avoir ajouté un deuxième périphérique

Personalities : [raid1]
md200 : active raid1 loop1[2] loop0[0]
      65408 blocs super 1.2 [2/2] [UU]

dispositifs inutilisés :

Cela ressemble plus à une question pour superuser qu'à serverfault, mais certaines idées sont valables pour ce site aussi, donc je vais essayer de répondre à certaines questions :

• XFS avait la réputation de ne pas aimer les coupures de courant. Beaucoup de choses se sont passées depuis, et RedHat, Oracle et autres l'utilisent comme système de fichiers par défaut de nos jours, donc je ne serais pas surpris si c'est un problème beaucoup moins important aujourd'hui qu'auparavant. Surtout si vous avez une politique de sauvegarde correcte, si votre cas d'utilisation bénéficie d'un avantage de vitesse avec ce système de fichiers, il pourrait valoir le risque éventuel.
• ZFS sans RAM ECC offre toujours de très belles fonctionnalités, mais vous courez le risque de ne pas détecter certains cas de mauvaises données. J'ai utilisé ZFS sans mémoire ECC pendant plusieurs années dans un environnement domestique similaire à ce que vous décrivez et je n'ai jamais connu de perte évidente de données, mais je n'ai pas exactement stocké de données critiques sur ce volume. J'ai depuis migré vers du matériel serveur approprié et je me sens beaucoup plus à l'aise pour utiliser réellement mon stockage pour des choses importantes maintenant.
• Avec ZFS, vous devriez simplement pouvoir ajouter un disque à un pool monodisque pour créer une copie en miroir. Je ne l'ai pas essayé en pratique, mais j'obtiens plusieurs résultats de recherche affirmant avoir réussi en vérifiant duckduckgo. Je ne suis pas sûr des autres systèmes, mais tant que vous avez un gestionnaire de volume quelconque sous votre système de fichiers allant de RAID1 à partir d'un seul disque devrait être trivial.
• Les systèmes de fichiers basés sur la technologie CoW (zfs, btrfs) sont plus lents que les systèmes moins riches en fonctionnalités, et ils dépendent davantage d'avoir un matériel suffisamment puissant pour les soutenir.

Tout comme dans un environnement professionnel, je prendrais certainement le temps d'effectuer des tests avec ma charge de travail attendue, pour acquérir une expérience pratique des performances par rapport aux fonctionnalités.

Je utiliserais le système de fichiers de journalisation que le système d'exploitation en question suggère par défaut, sauf si j'avais une très bonne raison de ne pas le faire. La dernière fois que j'ai vérifié avec Ubuntu, c'était ext4.

La raison est simple : le défaut est celui qui est le plus probablement utilisé le plus, donc la chance que des bugs aient été trouvés et corrigés est la plus grande. Les différences entre les systèmes de fichiers que vous mentionnez sont peu susceptibles d'avoir beaucoup d'importance dans une utilisation quotidienne. Si les performances sont très importantes, envisagez alors d'obtenir plus de mémoire afin que votre système d'exploitation ait plus d'espace pour le caching.

Cela dit, si vous devez utiliser le disque "à travers" des systèmes d'exploitation, je vous suggère d'en obtenir deux, ou du moins de diviser celui que vous avez en deux partitions physiques, puis d'utiliser soit NTFS soit exFAT sur celui où vous avez des médias.

Si vous vous souciez de l'intégrité de vos données à long terme, je vous suggérerais zfs ou btrfs.

Ma compréhension est que ce sont les seuls qui vous permettent de vérifier les données, de chercher et éventuellement de corriger la pourriture des bits.

Je ne suis pas très familier avec zfs, mais j'utilise btrfs depuis environ 5-6 ans. Je l'exécute en RAID1 et j'ai un travail de vérification hebdomadaire. (Note : si vous n'êtes pas en miroir, la vérification marquera simplement ces mauvais blocs au lieu de les réparer !)

Le seul problème que j'ai rencontré est qu'il y avait un bug où les étendues n'étaient pas libérées automatiquement, donc le disque se remplissait, mais n'était pas réellement rempli.

Les deux ont une compression et une déduplication, mais la déduplication de btrfs est hors ligne - ce que certaines personnes préfèrent.

Une autre ressource à vérifier est ce récent article qui a fait la une sur Hacker News : Cinq ans de Btrfs

Note : Il semble y avoir des travaux vers la vérification XFS/ext4

Vous pouvez créer un système de fichiers formaté XFS sur quelque chose qui est un miroir mdadm sans avoir un vrai miroir.

Créez la partition en tant que miroir avec trois miroirs mais deux absents. Plus tard, vous pourrez ajouter les deux manquants.