Après plusieurs articles sur la FAT32, NTFS, HFS+ ou encore APFS, il est temps de se tourner vers l’univers Linux, et plus particulièrement les deux systèmes de fichiers que l’on y trouve le plus souvent : ext4 et Btrfs. Ils se côtoient souvent, mais leur fonctionnement est très différent.
Lire notre dossier sur les systèmes de fichiers :
- Qu'est-ce qu'un système de fichiers ?
- Systèmes de fichiers : FAT12 à 32 et exFAT, conçus pour le grand public
- Systèmes de fichiers : NTFS et ReFS, pensés d’abord pour l’entreprise
- Systèmes de fichiers : de HFS et ses évolutions à APFS chez Apple
- Systèmes de fichiers : ext4 et Btrfs, les « frères ennemis » du monde Linux
Dans l’univers Linux, l’immense majorité des distributions se sert du même système de fichiers depuis longtemps : ext4. Le chiffre fait référence à la version. Il s’agit de la quatrième itération, même si l’on ne parlait pas vraiment à l’origine de « version » à proprement parler.
De nombreux utilisateurs francophones ignorent peut-être que la toute première version d’ext a été développée par un Français : Rémy Card. Docteur en informatique et actuellement responsable du pôle « Exploitation et Infrastructures » de la DSI de la Sorbonne, il a développé ce système de fichiers pour dépasser les limitations imposées par Minix fs, lui-même une version simplifiée du système de fichiers Unix. Parmi ces limites, on trouvait notamment une limite de 64 Mo pour la taille des partitions, ou encore des noms de fichiers ne pouvant pas dépasser 14 caractères.
Le système ext – extended file system – est intégré pour la première fois dans la version 0.96c du noyau Linux en 1992. Parmi ses apports, des partitions et des fichiers pouvant grimper jusqu’à 2 Go, ainsi que des noms de fichiers jusqu’à 255 caractères. Il garde la sémantique Unix et les bases posées précédemment, notamment les inodes.
Ces derniers sont centraux dans l’univers UNIX/Linux et étaient déjà présents dans Minix. Un inode est une structure contenant la description d’un fichier : son type, les droits d’accès, les propriétaires, les horodatages, la taille ainsi que des pointeurs vers des blocs de données. Toutes les adresses de blocs d’un fichier sont contenues dans son inode. Aussi, lorsqu’une opération d’entrée/sortie sur un fichier est demandée par l’utilisateur, le noyau convertit la demande en numéro inode, lui-même permettant ensuite d’accéder à tous les blocs du fichier.
Chaque dossier contient la liste des inodes des fichiers qu’il contient, selon le modèle suivant :
Pour autant, il ne va pas rester en place bien longtemps, ext2 étant proposé dès l’année suivante.
Cette évolution du premier ext vient en corriger les principaux défauts et étendre ses capacités. Alors que la taille des partitions avait fait un bond avec ext, ext2 propulse cette limite à 4 To (théoriquement jusqu’à 32 To). Si la taille maximale des fichiers n’évolue pas dans un premier temps (2 Go), elle le fera au cours des années suivantes, pouvant grimper jusqu’à 2 To.
Lorsque ext3 apparait en 2001, il introduit un apport majeur : la journalisation. Avec ext2 en effet, en cas de corruption de la structure des données (suite par exemple à une extinction mal faite de l’ordinateur), l’outil fsck (file system check) pouvait prendre beaucoup de temps à faire son travail.
Cette journalisation, contrairement à celle d’APFS par exemple, est totale. Elle concerne aussi bien les données que les métadonnées. L’idée générale reste cependant la même : les données et métadonnées sont entreposées dans une zone spécifique du disque, et ne sont intégrées dans la structure principale qu'à l'instant où le système de fichiers reçoit la confirmation que les informations ont été correctement écrites. Le journal est ensuite mis à jour. Au démarrage suivant, ce dernier sera analysé à la recherche d’opérations non terminées, qui seront alors répercutées si aucune erreur n’a été rencontrée.
En revanche, et comme on s’en doute venant d’un mécanisme pensé pour la fiabilité, la journalisation a un impact négatif sur les performances en écriture. Initialement, on pouvait d’ailleurs la paramétrer selon trois paliers, du plus performant au plus sécurisé. Il était également possible de la désactiver, auquel cas la partition fonctionnait comme ext2.
ext4 l'omniprésent
L’arrivée d’ext4 en version stable le 24 décembre 2008 est un tournant majeur pour les systèmes de fichiers sous Linux. Ironie de l’histoire, il n’était prévu que comme une solution temporaire en attendant l’arrivée d’un système de fichiers plus moderne, à l’instar de Btrfs. Pourtant, 15 ans plus tard, il est toujours là, qui plus est sur pratiquement toutes les distributions Linux. Il n’est plus porté par Rémy Card.
Les caractéristiques principales d’ext4 sont celles d’un système de fichiers tout ce qu’il y a de plus moderne. Les partitions peuvent grimper jusqu’à 1 Eo (un million de To), et les fichiers jusqu'à 16 To. Ces derniers peuvent être 4 milliards par volume. La limite de sous-dossiers passe également de 32 000 dans ext3 à 64 000. Les inodes voient leur taille passer à 256 octets (contre 128 pour ext3) et les horodatages abandonnent les secondes pour les nanosecondes.
Les extents, petite révolution en leur temps
Surtout, ext4 apporte plusieurs évolutions importantes, dont la principale est le mécanisme d’extent. Pour le comprendre, il faut se pencher un instant sur la manière dont un système de fichiers alloue l’espace aux données. ext2 et ext3 proposaient des schémas de mappage de blocs direct, indirect, double indirect et triple indirect. Sans plonger dans les détails, retenez que ces solutions sont très adaptées pour de nombreux petits fichiers, mais pas pour les gros. Avec ces derniers, ces schémas créent un grand nombre de mappages, réduisant les performances générales, surtout lors d’opérations comme la recherche ou l’effacement de données.
De son côté, un extent est défini par une séquence contiguë de blocs physiques. La création d’un fichier entraine celle d’un extent. Si le fichier est amené à grossir, les données ultérieures sont simplement inscrites à la suite de celles existantes au sein du même extent. Quand le fichier devient volumineux, plusieurs extents sont utilisés. L’inode d’un fichier peut stocker jusqu’à quatre extents, après quoi le reste est stocké dans un arbre H (similaire à l’arbre B vu dans ce précédent article). Les blocs étant contigus, les extents réduisent fortement la fragmentation et augmentent les performances vis-à-vis d’ext3. Des intentions confirmées dès décembre 2008 par Phoronix dans une série de benchmarks. Précisons que les extents étaient une option au début d’ext4, mais qu’ils sont devenus activés par défaut avec le noyau Linux 2.6.23.
Souplesse dans l'allocation des blocs
Cette hausse de performances est également alimentée par plusieurs capacités d’allocation, comme le multi-blocs. Si ext3 allouait les blocs un par un, ext4 peut le faire pour de multiples blocs en une seule opération, diminuant la charge du processeur et la quantité de mémoire vive utilisée. ext4 peut également faire de l’allocation différée, aussi appelée allocation à la volée. Si une opération écrit des données sans les allouer d’une seule traite, elles seront stockées dans un cache. Quand les tâches d’écriture sont terminées, le cache est vidé (allocate-on-flush) et les données sont allouées dans un extent. Ces deux types d’allocation réduisent elles aussi la fragmentation.
ext4 peut aussi faire de la préallocation persistante. Elle reprend les mêmes avantages sur la fragmentation que les autres, mais permet en plus aux applications de s’assurer que suffisamment d’espace est disponible avant d’écrire des données. Le mécanisme convient très bien par exemple aux bases de données ou aux processus chargés de diffuser du contenu en continu.
Notez que les extents ne sont pas une capacité unique d’ext4. Ce mécanisme d’allocation est par exemple présent dans NTFS chez Microsoft, dans HFS+ et APFS chez Apple, dans le HPFS d’OS/2, le BFS de BeOS ou encore dans des systèmes de fichiers plus récents comme Btrfs. Par ailleurs, si les systèmes de fichiers ext ont réduit la fragmentation version après version, ils ne l’ont pas totalement supprimée. Dans ext4, il existe un outil, e4defrag, dédié à cette tâche, capable d’agir aussi bien sur un fichier spécifique qu’un dossier ou un volume. Comme pour NTFS, le passage aux SSD met fin au problème.
Fiable et éprouvé, en attendant « mieux »
Outre ces aspects, ext4 gère d’autres caractéristiques, comme une double compatibilité ascendante/descendante avec les versions antérieures du système de fichiers (bien que plus limitée avec l’activation par défaut des extents), les attributs étendus (xattr), les quotas et leur journalisation (plus besoin des longues vérifications de leur cohérence), le chiffrement des données (depuis le noyau Linux 4.1) ou encore, bien sûr, la gestion des droits.
Une précision enfin sur l’accès depuis les autres plateformes. Dans l’absolu, il est possible de lire, voire d’écrire des données sur une partition ext4 depuis Windows ou macOS, mais pas sans utiliser un outil tiers, qu’ils soient libres (ext2read, LinuxReader, etx4fuse…) ou payants, comme les produits vendus par Paragon.
Aujourd’hui, ext4 est donc omniprésent. Peu de distributions Linux se servent d’autre chose, l’un des cas les plus emblématiques étant Fedora, dont la version 33 a adopté Btrfs pour les nouveaux volumes formatés par une installation neuve du système. Mais puisque l’on parle justement de Btrfs, pourquoi ce système de fichiers, en version stable depuis longtemps, n’est-il pas encore celui fourni par défaut sur les autres systèmes ? Nous allons nous pencher sur la question.
Btrfs, un gros projet
Parlons maintenant du système de fichiers qui doit prendre le relai, tout du moins dans une partie des distributions Linux. Btrfs est loin d’être un projet neuf, puisque la première version stable dans le noyau Linux 3.10 est sortie le 29 juillet 2013 (oui, Btrfs fête ses dix ans demain). Avant cette étape, il a passé plus de quatre ans en statut instable, après son arrivée dans le noyau Linux 2.6.29. Une gestation assez longue, dont on pourrait dire qu’elle n’est pas tout à fait terminée, tant Btrfs met du temps à parvenir jusque dans les installations par défaut.
Btrfs est initialement un projet commun de plusieurs entreprises, dont Fujitsu, Intel, Oracle, Red Hat (qui depuis s'est retiré) ou encore SUSE. Développé en open source (licence GPL), il tient son nom de l’arbre B (dont nous avons déjà parlé dans notre article sur NTFS) : B-tree file system, que l’on prononce « ButterFS ». Ses caractéristiques de base sont clairement modernes : 16 Eo de taille maximale pour les volumes et les fichiers, 2^64 fichiers possibles par volume, noms jusqu’à 255 caractères, attributs POSIX et étendus, reprise des extents…
La protection et l'intégrité des données avant tout
Ce qui rend Btrfs si désirable aux yeux d’une partie des utilisateurs, ce sont ses fonctionnalités. Deux sont en particulier importantes : le copy-on-write (copie sur écriture) et les snapshots (instantanés).
Nous avons déjà évoqué le premier, mais il faut l’expliquer à nouveau, car il est au cœur de Btrfs. La copie sur écriture fait exactement ce qu’elle annonce : lorsque des données doivent être écrites sur un bloc occupé, par exemple dans le cas d’une mise à jour d’un fichier, les données originales sont copiées dans une autre zone pour être modifiées. L’avantage est évident : les données d’origine restent accessibles en cas de besoin. Les métadonnées sont mises à jour dans la foulée pour tenir compte des données ajoutées. Ce mécanisme, couplé à l’arbre B, élimine le besoin d’un journal.
Les snapshots découlent directement du copy-on-write. Les instantanés permettent, à la manière de photographies, de capturer à un instant T l’état du volume dans un état cohérent. Cette caractéristique fait de Btrfs un système de fichiers tout indiqué quand la haute disponibilité est recherchée, par exemple avec les bases de données. Les instantanés sont en effet traités comme des sous-volumes, restent accessibles à l’écriture et peuvent se faire en parallèle d’autres actions, de manière très rapide puisque consommant peu de place. Dans le cadre d’une utilisation quotidienne, un système Linux peut ainsi revenir facilement à un état antérieur, puisque des snapshots peuvent être créés. Un projet, nommé grub-btrfs, permet même de démarrer directement vers un snapshot depuis le Grub.
Notez que l’on parle ici de sous-volumes, qui font partie du jargon de Btrfs. C’est l’équivalent des volumes logiques dans d’autres systèmes de fichiers, comme ceux que l’on a pu voir dans APFS. Les sous-volumes réagissent comme des partitions, mais n’en sont pas. Leur fonctionnement est beaucoup plus simple, avec la possibilité notamment de les redimensionner à la volée. Au sein d’un volume, tous les sous-volumes partagent le même espace. Les volumes et sous-volumes peuvent en outre s’étendre sur plusieurs disques physiques.
Puisque Btrfs a avant tout été pensé pour la protection des données, d’autres fonctions viennent compléter la trousse à outils. Par exemple, le système de fichiers se sert de sommes de contrôles (checksums) pour vérifier l’intégrité aussi bien des données que des métadonnées, certaines corruptions de données pouvant être réparées à chaud. Dans le domaine des corruptions, justement, Btrfs gère également les références arrière (back references). Elles permettent, à partir d’un bloc de données, de retrouver les métadonnées pointant vers ce bloc. On peut ainsi relever certaines corruptions, quand un fichier déclare appartenir à un certain bloc, mais que ce dernier déclare relever d’un autre fichier.
Btrfs gère également la compression des données, en laissant le choix entre trois algorithmes : zlib, LZO et zstd. Comme indiqué sur la page Wikipedia du système de fichiers, LZ4 est envisagé depuis plusieurs années, mais n’est toujours pas présent.
Bon, mais pourquoi n’est-il pas partout avec autant de qualités ?
La question est légitime, car avec de telles caractéristiques et fonctions, Btrfs ressemble au graal des systèmes de fichiers. Cependant, comme nous l’avons déjà vu, un système spécifique ne peut pas répondre à tous les cas d’utilisation. Et si Btrfs a été pensé pour protéger avant tout les données, la sécurité a un coût.
Btrfs consomme en effet une grande quantité d’espace disque pour l’ensemble de ces mécanismes. On considère, dans les grandes lignes, que l’espace réellement utilisable sur un disque correspond à sa taille maximale divisée par 2. C’est un point capital dans l’utilisation de Btrfs. Il nécessite que les personnes l’utilisant soient pleinement informées lors du choix, car tout le monde ne sera pas disposé à « sacrifier » la moitié de son stockage pour la sécurité des données.
Notez cependant que ce constat est plus ou moins vrai en fonction de l’utilisation que l’on choisit de faire. Les snapshots, par exemple, ne sont pas obligatoires. En fonction de la distribution, et même s’ils sont activés par défaut, on peut couper la fonction, économisant un espace non négligeable, surtout avec le temps. Cela se fera bien sûr au détriment de la fiabilité.
L’autre grand problème est le support des RAID 5 et 6. À l’heure actuelle, en se basant sur la page de statut des différentes fonctionnalités de Btrfs, ce support est toujours labellisé comme « instable ». Les Raid 5 et 6, en particulier, sont courants dans les configurations de type serveur. Sans pouvoir les utiliser, Btrfs ne peut pas être choisi dans ce type de cas.
La fragmentation est un autre souci de Btrfs. De par son fonctionnement, elle augmente mathématiquement avec le temps. Si vous utilisez ce système de fichiers sur un SSD, cela ne fera aucune différence (comme nous l’avions noté pour NTFS). En revanche, avec des disques mécaniques classiques, le problème peut prendre de l’importance.
Enfin, signalons que Btrfs ne prend pas en charge de chiffrement des données au niveau du système de fichiers.
Un passage de relai qui se fait attendre
Aussi, choisir aujourd’hui entre ext4 et Btrfs n’est pas si simple. Le premier a l’avantage d’une longue fiabilité éprouvée par le temps du fait de sa très large utilisation. Il ne possède pas les fonctions poussées de protection des données de son concurrent, mais il a pour lui de pouvoir profiter de la quasi-totalité de l’espace disque et de présenter très peu de fragmentation. Btrfs, de son côté, est très flexible. Les données qu’il gère sont mieux protégées et sa plus grande modernité lui permet d’envisager des scénarios plus spécifiques, avec d’énormes quantités de données.
Son utilisation par défaut dans les distributions Linux est donc encore rare. Les deux exemples les plus connus sont Fedora et openSUSE. Dans les deux cas, le volume root est configuré avec les snapshots, mais pas home, pour limiter la consommation d’espace disque. Libre aux utilisateurs cependant d’y activer aussi les instantanés.
Cette présence limitée est représentative d’une certaine attente, car il est impossible de répondre à la question « quel est le meilleur entre ext4 et Btrfs ? ». Ce dernier devrait cependant gagner petit à petit en utilisation, mais il faudra que certaines fonctions soient pleinement stables, notamment la gestion des modes RAID.
Commentaires (69)
#1
Je ne saurais vraiment expliquer pourquoi, mais j’ai la sensation que Btrfs a une sourde réputation de non fiabilité qui a énormément freiné son adoption. Un problème de communication à l’origine du projet probablement, notamment sur la documentation et les espaces de discussion des différentes distributions. Réputation qu’il se traîne encore un peu aujourd’hui, visiblement de manière totalement injustifiée.
Dans tous les cas merci encore pour cette série d’article, c’est très intéressant.
#2
“Les partitions peuvent grimper jusqu’à 16 To, tout comme la taille maximale de fichiers”
Ca m’étonne que les partitions soient limitées a 16To quand même sur ext4.
J’ai un raid 5 mdadm sur mon NAS avec des disques 8 To :
A moins que j’ai raté un truc …
#2.1
Pareil, j’ai un volume de 28To sur ma machine de lab…
La limite de ext4 c’est 64Zebibyte.
#2.2
T’as raison, l’auteur a fait une “petite” erreur, largement excusable.
https://en.wikipedia.org/wiki/Ext4
C’est 1 EiB le max pour une partition donc. 16 To c’est la taille max d’un fichier (!).
#2.3
Possible au fait que l’auteur a, dans les articles précédent, corrélé la taille max d’un fichier avec la taille max d’une partition en présentant les autres FS.
On le salut au passage, merci @Vincent pour le dossier !
#2.4
En fait 16To c’est la limite initiale, qui a été repoussée par la fonctionnalité “64 bits” (2^64 blocs maximum en théorie, en pratique 2^48).
https://www.kernel.org/doc/html/v6.4/filesystems/ext4/overview.html#blocks
#2.5
Toutes mes excuses, l’erreur a été corrigée
#2.6
Merc i pour ce dossier vraiment passionnant !
#3
Frères ennemis? La parenté n’est pas évidente… par contre si le but est de chercher du drame et du sang, il y a toujours ReiserFS …
#3.1
Ça va qu’on est vendredi. La blague est valide
#4
Super cette série sur les FS! Merci :)
Btrfs :
“Les instantanés sont en effet traités comme des sous-volumes, restent accessibles à l’écriture”
Pour moi le but étant de restaurer l’existant à un instant T, je ne comprends pas l’intérêt d’avoir des snapshot en R/W.
En plus, le snapshot en lecture seule, ça me semblait une protection contre les ransomware.
#4.1
L’outil snapper les passes en lecture seule par défaut
#5
Red hat propose xfs par défaut à priori.
#6
À noter qu’en pratique une lecture/écriture séquentielle sur un SSD est plus rapide qu’une lecture/écriture aléatoire (même si la différence est bien moins dramatique que sur un disque) à condition qu’on touche le cache du SSD. Le cache finit par s’épuiser pendant les opérations continues et là les lectures aléatoires sont effectivement tout aussi rapides.
La règle de “capacité / 2” sur btrfs, en tout cas pour mon utilisation sur pc personnel ne me semble pas vraiment correspondre à la réalité. À moins de garder des instantanés sur des années j’observe plutôt 10% maxi d’utilisation supplémentaire.
Les outils btrfs-send et btrfs-receive sont d’ailleurs très utiles pour transférer des instantanés, y compris par réseau et avec transfert incrémental (on envoie uniquement les données qui ne sont pas déjà présentes sur le btrfs distant).
#7
Exemple (mais pas en BTRFS):
…
Maintenant tes VMs partagent l’OS de base + les applis installées avant le snapshot et seules les modifs pèsent.
Utilisé pour génrer des serveurs Citrix à la volée qui pèsent moins lourds
#7.1
OK, merci pour la démo!
#8
“comme une double comptabilité ascendante/descendante avec les versions antérieures du système de fichiers”
C’est en €uros ?
“il a passé plus de quatre en statut instable”
choucroutes
Plus sérieusement, merci pour ce dossier pointu.
#9
Le problème de btrfs et du raid peux se contourner facilement via l’utilisation de mdadm sans problème (c’est le raid5/6 en direct sur les disques qui comporte le bug du “write hole”)
Par contre ce qui manque cruellement a btrfs c’est les interfaces web de gestion !
Car il y a ce qu’il faut pour mdadm, lvm, extX, xfs, zfs, … Mais btrfs, rien que pour gérer des subvolumes, j’ai rien trouvé d’actif.
#10
Sous Fedora sur mon laptop en btrfs (ssd nvme), j’ai souvent des freezes de plusieurs secondes lors d’un gros DL, ou lors du lancement d’une VM. Le cpu et la ram sont OK.
J’ai toujours soupconné le copy-on-write de btrfs…
Je comprends (j’imagine !?) que la modification d’un gros fichier entraine une ré écriture conséquente. Ce qui bloque les autres opérations d’IO sur le disque ?
Ça reste une idée et je ne suis sûr de rien, mais le laptop passera quand même par une réinstallation en ext4 pour tester… Au revoir les snapshots de Timeshift bien pratiques
#10.1
Kubuntu 22.04, Ext4, Timeshift se comporte bien :-)
Et pour restaurer, on peut faire sans lancer le système (faut voir la procédure aujourd’hui, mais je l’avais déjà fait dans le passé).
#10.2
Le CoW n’est pas forcément recommandé pour des VM ou des grosses DB.
De mon humble expérience, j’ai eu à travailler avec une base de données de 300 Go sur mon laptop pour de l’analyse statistique. J’avais effectivement observé des ralentissements et des perfs moindres malgré un SSD.
Après désactivation du COW sur la BDD uniquement, ça allait beaucoup mieux. Mais comme dit plus haut, ça veut dire perte des snapshots (et sur une BDD c’est parfois pratique comme sécurité complémentaire au rollback).
#10.4
Yep, ext4 sur ssd optane pour la base c’est le feu.
#10.5
Pour info, désactiver CoW localement (avec
chattr +C) ne fais pas sauter les snapshots (Btrfs désactive alors temporairement le nocow le temps de faire le snapshot). Par contre tu perds le contrôle d’intégrité (checksum).Si tu le désactives sur la partition entière, aucune idée, par contre.
#10.6
Merci pour la subtilité je l’ignorais.
Pour un subvolume, c’est pareil si j’en crois ce thread SO.
#10.3
Faut désactiver CoW que pour le fichier disque de ta machine virtuelle, kvm/qemu peut gérer lui-même tes instantanés si t’es sur du qcow
#11
J’ai jamais lu ça nulle part, et en pratique c’est pas du tout ce que je constate. Les snapshots peuvent effectivement prendre pas mal de place, cela dit, donc ça dépends effectivement de l’usage.
Mais en général, on ne parle de quelques % largement compensés par la compression et/ou la déduplication selon l’usage qu’on en fait. Perso j’ai gagné de la place en passant à Btrfs grâce à ces deux fonctionnalités.
Et en Raid 5⁄6, en réalité, le problème le write hole existe dans la plupart des systèmes de RAID logiciel, il faut pour le provoquer avoir à la fois une corruption de données et une extinction inopinée du système, en pratique c’est suffisamment rare pour être utilisé en production par un certain nombre de personnes (notamment sur des données pas trop critiques ou correctement sauvegardées, avec une vérification régulière de l’intégrité).
Et pour la plupart des usages, que ce soit sans RAID, en RAID 1 ou 10 (qui permettent d’utiliser 50 % de l’espace total peut importe le nombre de disques et presque peu importe leur taille, ce qui est un gros avantage par rapport à d’autres technos), ça ne pose donc pas le moindre problème.
Et une solution mentionnée plus tôt, est d’utiliser une autre techno pour gérer le RAID56 et btrfs par-dessus, dans le pire des cas.
#12
Concernant l(e manque d’)adoption de BTRFS, voici mon point de vue.
Sur le desktop :
Les aspects utiles de BTRFS, se sont surtout les snapshot. Cela permet de gérer facilement les mises à jour et de revenir en arrière en un clin d’oeil si les choses tournent mal.
Mais BTRFS requiert un apprentissage, de nouveaux concepts et de nouveaux outils. Il faut mettre les mains dans le cambouis. Pas de GUI, CLI only. Les choses ont peut être changées depuis, puisque je n’ai pas regardé depuis quelques années ce qu’il en était.
Sur les serveurs
Les aspects utiles de BTRFS sont la déduplication (notamment pour les hyperviseurs), les snapshots, et les RAID.
RAID n’est pas prêt pour un usage en production. Il faut donc rester sur une stack plus “classique” à base de LVM par exemple.
La déduplication nécessite de faire tourner régulièrement des outils en espace utilisateur (maintenance)
Sur des serveurs, notamment avec beaucoup d’I/O, il n’est pas rare d’avoir des disques durs spécifique (et non des SSD). Le COW peut alors être un véritable goulet d’étranglement niveau performance (notamment à cause de la fragmentation) au point que certains administrateurs recommandent purement et simplement de… désactiver le COW, et donc perdre certaines fonctionnalités comme les snapshots ! Et du coup, perdre l’intérêt de BTRFS.
A noter également que pour des usages en production sur des serveurs, on est généralement beaucoup plus “conservateur” sur les technologies utilisées : on souhaite de l’éprouvée !
Conclusion
Sans nier les apports de ce système de fichiers, il n’est pas sans inconvénients. C’est un système de fichiers qui dépasse le rôle d’un système de fichiers “classique”, car peut gérer des disques/partitions directement (d’ailleurs, la déduplication n’a pas été abordé dans l’article !). Les systèmes plus classiques se contente de venir organiser les données au sein d’une partition unique. Si le besoin se fait ressentir d’agglomérer des partitions/disques (pour avoir de la redondance ou étendre la capacité via des mécanismes comme RAID), alors c’est soit du RAID matériel, soit du RAID logiciel.
Notons aussi que si la première version stable de BTRFS date de 2013, toutes les fonctionnalités ne sont pas arrivées en même temps. Elles arrivent au fil de l’eau, donnant une fausse impression de système de fichiers à demi-fini et donc non stable.
#12.1
J’utilise le raid miroir de btrfs en production depuis plusieurs années, personne ne conteste son bon fonctionnement.
#12.2
Pardon pour l’imprécision. Comme je n’utilise que des raids 5 et 6, j’ai tendance à me focaliser sur eux ^^
Les RAIDs 5 et 6 ne sont pas prêt pour de la production (et c’est la doc qui le dit).
Par contre, effectivement, les RAID comme 0 ou 1 (miroir, celui que tu utilises) sont tout à fait utilisable. Merci pour la correction ;)
#13
Je me souviens d’un forum où quelqu’un se posait la question “ext ou RFS ?”. Quelqu’un avait répondu : “ext n’a jamais tué personne”
+1. Si la “place perdue” c’est les snapshot, c’est pas perdu, c’est une “sauvegarde”. Pour avoir la même chose sans ce mécanisme, il fallait copier les données.
#13.1
Les snapshots, c’est bien mais ça doit rester temporaire. Par exemple tu veux faire un backup d’un système sans interrompre les transactions disque, tu utilise un snapshot pour créer une réplique du volume figée dans le temps et tu fais le backup de cette réplique… puis tu jette la réplique après usage… Comme le snapshot va préserver dans leur état d’origine tous les blocks concernés par des changements ultérieurs, il faut dimensionner le snapshot pour qu’il puisse stocker à minima tous les changements pouvant se produire pendant la durée du backup.
Les snapshots “qui prennent beaucoup de place” sont souvent le résultat de mauvaise utilisation du snapshot… un snapshot n’est pas supposé être permanent. Et ne jamais considérer un snapshot comme un système d’archivage, car sa viabilité est liée au même matériel que les données qu’il fige.
#14
Tu peux faire du raid 5 ou 6 pour les données mais du miroir pour les métadonnées… il me semble que ça résout tout.
#15
Aujourd’hui sur les SUSE Sles 12 et Sles 15 (et leur équivalents opensuse 42 et 43 je crois…) c’est disque système en btrfs ou ext4, et disques “data” en ext4 ou xfs conseillés. Et pour les snapshots, gérés avec snapper, c’est de base sur le subvolume / qui contient + ou - tout ce qui est installé et désinstallé par les packages RPM, permettant de revenir en arrière en cas de problème de mise à jour. Les / home, /var et autres plus “volatiles” sont d’autres subvolumes non gérés par snapper par défaut.
Globalement ça marche bien (sauf entre 2019 et 2021 où des gros bugs ont créés quelques corruptions lors que les serveurs faisaient beaucoup d’ecritures). Le seul trucs que je n’ai jamais trop compris, c’est pourquoi /var et ses subvolumes où on attend beaucoup d’écritures n’ont pas à minima été montés par défaut sans le copy on write, en particulier /var/log. Voir qu’on ai pas utilisé pour ces répertoires des systèmes de fichiers plus adaptés comme ext4 ou xfs.
#16
Merci infiniment pour cet exposé précis d’Ext4 et Btrfs qui répond aux questions que je me posais !
Cela faisait longtemps que je n’avais pas testé une distri, là ça fait deux semaines que je joue avec Debian 12 “Bookworm”, que je trouve vraiment intéressante et stable, bien plus souple qu’ubuntu en tout cas. Je me demandais justement pourquoi, après toutes ces années, c’est toujours Ext4 le Fs par défaut.
(J’attends avec impatience que Mint en sorte sa version LMDE 6 kivabien, mais ils ont pas l’air spécialement pressés, ils doivent certainement manquer de p’tits bras velus pour les aider. Et pourtant je trouve que cette version devrait être la priorité, pour enfin se débarrasser d’une base Ubuntu omnipotente et omniprésente.)…
… J’en profite pour réitérer ma question à propos de ce (vieux) projet de fs qui transforme tes disques en une base de données géante, interrogeable exactement comme telle, avec des tags (critères ?) illimités, et un langage d’interrogation comparable à Oracle / Access / SQL / mets-ton-préféré-ici…
L’avantage serait (aurait été ?) que la notion de partition disparaît, au profit d’un système extrêmement souple qui peut s’étendre sur autant de disques que l’on veut, le tout étant quoi qu’il en soit considéré comme une seule et même base de données de fichiers d’une taille véritablement illimitée.
De mon point de vue limité, il me semble qu’un site web peut fonctionner de cette façon, non ?
L’avantage d’utiliser un système de type SGBD m’apparaît évident : une rapidité et une précision inégalée dans la recherche de fichiers / documents (que je trouve toujours aussi horriblement lente en général), on peut même interroger le système d’un façon floue (“Trouve-moi le document que j’ai créé l’année dernière concernant une femme Irlandaise rousse aux yeux verts… Et arrête de me traiter de pervers, steuplé, il s’agit d’une cliente tout ce qu’il y a de plus respectable”
).
Je trouve que l’on parle d’AI un peu trop à tord et à travers, mais cela fait longtemps, très longtemps AMHA que les SGBD et leurs langages / algorithmes d’interrogation ont atteint une maturité, une complexité et une subtilité que l’on peut véritablement considérer comme “intelligente” …L’avenir ?
#17
En tous cas je réitère ce que je vous ai suggéré sur l’article au sujet de la ligne éditoriale : compilez ce genre de dossier en e-pub et publiez-les ne serait-ce que sur la plateforme Kindle (parce qu’en regardant je crois que les autres ont la sale manie de faire de l’abonnement pour les auteurs, mais j’en ai pas comparé 12 000 non plus).
Si un gus comme moi a vendu une paire d’exemplaires comme ça sur un premier essai, vous n’avez rien à perdre et ça sera toujours un revenu de plus pour l’entreprise. Et vu la qualité du contenu, foncez.
#17.1
Bien entendu, mais ce que j’ai pu constater : ce qui rapporte le plus, ce sont les formations en présentiel.
NXi pourrait par exemple s’associer à une université / fac locales pour produire des stages de formations / reconversions pro, en partenariat avec la mairie, la région, pole emploi, l’apec…
Comme ça, pas besoin de prévoir de locaux, de tables, de chaises, etc… tout ça serait fournit par l’établissement. Pour tout ce qui est matos spécifique, les institutions sont là pour ça : des demandes de subventions pour des choses très précises, tels que des switches pour mettre tout le monde en réseau (si la formation porte sur les réseaux, chaque élève apporte sa bécane), des modems, des répéteurs, des câbles, etc…. ce n’est pas la mer à boire.
Autre exemple, la maintenance informatique est un secteur qui continue de marcher, bénéficier d’une formation pro dans ce domaine n’est pas négligeable, lorsque tu es au chômage.
#17.2
Nous avons bien noté l’idée
#17.3
#18
Pour un volume de données, direct XFS. Il est fiable, évolue régulièrement et a très peu de soucis. À savoir pourquoi le système ne bascule pas dessus. Un seul soucis avec XFS, il n’y a pas d’outil pour réduire un volume (possible sur le principe mais jamais été programmé).
#19
À noter que nous avons remarqué sur notre parc que cela fonctionne mieux d’avoir de l’EXT2 sur la petite partition /boot (peu souvent en écriture) que de l’EXT4. À savoir pourquoi ?
#20
Pour avoir dispensé une paire de formations en tant que freelance, oui ça met clairement du beurre dans les épinards de la régie vu qu’il s’agit de prestations courtes un peu plus rémunérées. Mais par contre ça prend du temps à préparer, donc même si je suis d’accord avec toi sur l’intérêt, j’ai peur qu’ils n’aient pas les ressources qui vont avec.
#21
Du coup, est-ce que Btrfs a été créé pour répondre à ZFS ?
Parce que y’a 20 ans, on vantait les qualités de ZFS avec ses possibilités quasi infinies. Mais au final, j’ai l’impression que personne l’utilise.
SGBD-FS n’est pas une excellente idée : le principe des systèmes de fichiers, c’est de prendre en compte les limitations du matériel, tout en y donnant accès le plus rapidement/efficacement/sûrement possible.
Or, un SGBD ne peut pas se mapper directement à du matos. Parce que soit tu as les méta-données centralisés, ce qui accélère les requêtes, mais fait que lorsque tu veux accéder pour de vrai aux fichiers, ça prend du temps, ou c’est pas centralisé, et les requêtes prennent un temps fou, alors que l’accès aux fichiers est rapide.
Par contre, ce que tu décris existe déjà et est largement utilisé. Mais pas en tant que système de fichiers.
Il s’agit de l’indexation de fichiers. En gros, t’as un démon qui scrute ton système de fichiers, et stocke les métadata de manière centralisée. Du coup, tu peux faire ta recherche extrêmement rapidement.
Certes, c’est pas en SQL, mais j’suis sûr que y’a des outils pour faire la traduction.
#22
BFS pouvait le faire, NTFS en a une partie avec les flux alternatifs…
C’est intéressant pour un FS dédié “documents”, mais au final c’est plutôt du stockage objet minio , webdav ou même sharepoint qui va répondre à cela. Le problème c’est la synchro entre les métadonnées et les documents: le FS doit-il suspendre les lectures ou écritures le temps d’indexer un doc?
Le stockage des métadonnées dédiées + indexation apporte des contraintes au niveau du FS qui sont difficilement compatibles avec des fichiers “appli”.
Bien que actuellement, je reconnais que les logiciels sont beaucoup plus sur du stockage document que sur des principes de modification de fichier niveau bloc - ce type de fonctionnement étant surtout rencontré sur les SGBD justement.
Les SGBD d’ailleurs, en tout cas SQL Server, ont leur propre implémentation de “FS” intégrée sur la plage des fichiers de données.
Bref, chaque FS a ses avantages, et parfois il faut choisir celui qui correspond à ses besoin - ou plutôt ne pas choisir celui qui va à l’encontre de ses besoins :)
#23
Je trouve curieux de ne pas parler de ZFS dans l’article, qui est de mon point de vue le choix pertinent, surtout en usage “serveur”. On y retrouve les fonctionnalité de btrfs, avec une souplesse incomparable, et des fonctions avancées comme le mélange HDD+SSD avec le SSD en cache, du RAID modifiable à la volée…
Btrfs j’ai eu trop d’ennuis avec en prod pour le considérer.
Le soucis est qu’ext4 n’était pas sensé rester longtemps, de l’avis même de son auteur :
https://en.wikipedia.org/wiki/Ext3#ext4 :
In 2008, Ts’o stated that although ext4 has improved features such as being much faster than ext3, it is not a major advance, it uses old technology, and is a stop-gap; Ts’o believes that Btrfs is the better direction, because “it offers improvements in scalability, reliability, and ease of management”.[45] Btrfs also has “a number of the same design ideas that reiser3/4 had”
Bon, Reiser est possiblement libérable sur parole cette année, faut voir si ca met un peu de sang neuf dans le milieu
#23.1
ZFS sera probablement pour un autre article de la série. Celui-ci s’intéresse aux FS de Linux, et ZFS n’en fait pas partie. Linus refuse de l’inclure, parce que la licence et Oracle (ec sa facheuse tendance à faire des procès) lui font peur.
#23.2
Ce n’est pas une question de peur ou de procès de la part d’Oracle, c’est une question que la licence de ZFS est incompatible avec la licence du noyau, ce qui rend impossible d’intégrer ZFS directement dans le noyau. Il suffirait qu’Oracle change la licence et ZFS pourrait être intégré comme techno de premier rang , mais il semble qu’Oracle s’en fout éperdument et n’ait de toutes façons pas envie de faire des cadeaux à la communauté.
Dans le milieu pro, ZFS était surtout utilisé sur Solaris et on le retrouve encore dans des distributions BSD orientées stockage ainsi que des appliances (sous BSD)… BSD ne souffrant pas d’incompatibilité de licence.
#23.3
C’est une question que Linus a peur que la licence ne soit pas conpatible avec le noyau, ce qui est sujet à débat, et refuse de d’intégrer ZFS dans Linux sans lettre d’Oracle explicitant que la licence du résultat (ZFS+Linux) soit toujours bien GPL. Sans ça il a trop peur du procès.
Voici un article l’expliquant mieux que moi, avec des sources. On y apprend par exemple que Canonical pense que le résultat c’est bien du GPL, et distribue donc Ubuntu en GPL avec le support de ZFS.
#23.4
La licence n’est pas compatible, et personne d’autre qu’Oracle n’a le droit de changer la licence de ZFS, c’est tout… Une lettre n’est pas suffisante, ce qu’il faut c’est une distribution sous GPL2 en bonne et due forme.
Après qu’oracle soit une entreprise avec une nature prédatrice et belliqueuse digne des pires trolls du système légal, ça n’aide pas.
#23.5
On peut aller loin comme ça… Torvalds, Canonical et d’autres ne sont pas d’accord avec toi. Après t’en fais ce que tu veux.
L’histoire de la lettre, c’est pas de moi, c’est de Linus lui-même.
Canonical fournit ZFS avec Linux, sous licence GPL. Ils ont pris le risque de dire que c’est compatible niveau licence.
Personne ne peut dire que les licences sont compatibles ou incompatibles. Il y a des avis, mais c’est du débat stérile tant qu’Oracle n’aura pas officiellement donné son avis. Ou collé un procès. Dans le doute, Linus dit non, Canonical dit oui.
encore un avis, et un autre. Chacun dans un sens différent.
Bref, c’est pas du tout aussi simple que de dire licence incompatible, basta.
#23.6
Bien sûr que si, on peut savoir si elles sont incompatibles ou non, à moins de ne pas comprendre les mots des textes des licences en question.
La CDDLv1 et la GPL2 sont toutes-deux copyleft concernant le code source et aucune de ces licence ne stipule que le code peut être re-licencié sous l’autre en cas d’intégration (certaines licences ont des clauses indiquant que le code peut être passé sous GPL2 si nécessaire, mais ce n’est pas le cas de la CDDLv1
Par contre, contrairement à la GPL2, la CDDLv1 permet de redistribuer les binaires sous la licence de son choix. C’est ambiguïté par laquelle Canonical s’est engouffré pour publier les binaires de ZFS sous GPL2 même si le code source est en CDDL, et c’est le point qui est le plus problématique pour la communauté du logiciel libre (trahison de l’esprit de la licence GPLv2, oui, trahison de la lettre de la licence GPLv2, pas sûr)
L’intégration de ZFS dans le noyau implique d’aller plus loin que de complier et lier un module tiers, il s’agit d’intégrer les deux projets dans un seul… et pour cet objectif bien précis, les licences ne le permettent pas car aucune ne permet de changer la licence en cas d’intégration.
La seule manière de sortir de cette situation est qu’un des deux projets (noyau Linux ou ZFS) se fasse republier sous une licence compatible avec l’autre, mais il est improbable que cela arrive.
#24
Supers articles merci beaucoup !
#25
Erreur ! Bien sûr, cela dépend du SGBD, et tous ne le font pas, mais c’est possible. SQL Server le fait. Parmis les “options” disponibles :
Rien qu’avec ça, il est possible, sur des disques à plateaux, de gagner un facteur 3x à x10 ! Mais attention à ne pas lancer l’outil de défragmentation de disque derrière
Par contre, aujourd’hui, avec la virtualisation, on créé souvent des pertes de performance dû aux multiples couches d’abstraction des espaces de stockage.
#25.1
Merci pour vos réponses ! C’est un article que j’avais lu il y a… vingt ans environ (!) sur… Atari magazine (ou était-ce Amiga mag ? Autre ? Impossible de me rappeler…) qui évoquait cette possibilité comme “révolutionnaire”.
Pour vous situer, c’était la grande époque des Mandrake et autres distris orientées “grand public”, et donc l’article était principalement centré sur Linux, évoquant la possibilité d’installer “à la mano” (à l’époque, c’était du bricolage) une distribution sur un Atari ST (ou un Amiga ?).
Le seul passage qui m’a réellement intéressé était celui qui parlait des fs, et notamment de leur défauts (manque de redondance et de sécurité - pas de correction d’erreur -, lenteur, etc…), et donc au passage a évoqué cette possibilité, que j’ai trouvé passionnante.
C’est vrai que, comme @Wosgien l’écrit, le problème semble être l’indexation, ou plutôt le temps que cela fait perdre. Mais si cette indexation est faite dès la création du fichier, en même temps que l’écriture ? D’ailleurs c’est un peu ce que fait spotlight sous macOS, il indexe tout dès le départ, dans un thread indépendant, avec une priorité minimale, ce qui fait qu’il ne prends pas (trop) de temps processeur.
En tout cas le processus est totalement “invisible” pour l’utilisateur final. Mais le problème, c’est que spotlight est loin d’être neutre et universel. En particulier, il donne la priorité aux types de fichiers les plus connus, les plus “bateaux” et “grand public” (pdf, fichiers audio, vidéo, photo, documents de type “Office”…), en “oubliant” (volontairement) les autres (fichiers systèmes, frameworks, scripts, extensions, librairies…).
Je déteste ce côté “censure” des produits Apple en général, qui favorisent la “bof attitude” et le consensus mou, et décourage fortement ceux qui veulent aller plus loin et prendre en main leur système, peut-être pas à 100% (il faudrait pour cela avoir bien plus de connaissances techniques que votre serviteur), mais tout de même…
Il faudrait donc :
un système d’indexation “neutre” (qui n’oublie et ne cache rien - bien évidemment que les fichiers système et perso doivent être protégés, avec ACL et tutti quanti, mais cela n’empêche aucunement une certaine transparence),
qui intervient en même temps que l’écriture,
qui réserve de l’espace entre les fichiers pour de futures modifications (comme le font déjà très bien et depuis longtemps les fs les plus connus, afin d’éviter la fragmentation), et surtout…
permet d’accompagner chaque fichier d’un nombre de “tags” / de mots-clés (critères de recherche) quasi-infini,
qui permette le chiffrement sans (trop de) ralentissement, en utilisant le GPU ou un autre accélérateur spécialisé type T2…
et surtout qui possède un langage d’interrogation ultra-simple d’accès (au premier niveau, on peut utiliser le plus naturellement du monde *, ?, OR, XOR, NOT, etc… - AND serait implicite, comme sur les moteurs de recherche - et un second niveau, si on veut / peut / doit approfondir, avec de véritables requêtes de type SQL, ou même des formules mathématiques ? Même si la sécurité est importante, on ne devrait pas sentir de limites à la complexité des requêtes)…
Ceci dit, on pourrait très bien imaginer prendre une distri classique (type Debian, (pas du tout) au hasard), et y intégrer ce système d’interrogation, mais ce serait moins efficace que si c’était prévu dès le départ.
#26
Règle immuable de l’IT : toute solution temporaire est permanente.
#26.1
Sauf que non, on utilise presque plus ext4 … XFS l’a supplanté dans pas mal de scénarios.
#26.2
Pas du tout, non. Je pense que XFS est moins utilisé que Btrfs ou ZFS en pratique, d’assez loin… et ext4 reste très très loin devant.
#26.3
ça dépend… dans le monde professionnel utilisant RHEL ou dérivé, c’est XFS en standard depuis longtemps.
BtrFS et ZFS ne sont pas supporté par RHEL, ce qui les exclue de-facto d’une large part de marché.
Btrfs a une réputation d’instabilité qui lui colle encore à la peau dans le milieu professionnel, ce qui freine son adoption. Le fait que SLES l’incorpore par défaut devrait aider à pousser son adoption, mais de nombreux sysadmins préfèrent faire du LVM thin+XFS sur SLES.
Quand à ZFS? En environnement GNU/Linux pro, ça doit vraiment rester anecdotique et en environnement bureautique, ça n’a aucun intérêt.
ZFS est surtout populaire dans les distributions BSD (qui ne sont pas des GNU/Linux) , les OS pour NAS (basés sur BSD) , et Solaris (la plateforme d’origine de ZFS, qui est occupée à vivre sa fin de vie).
#27
moi non plus je n’ai jamais vu de telles affirmations, et je dirais même plus : grâce à la compression et à la déduplication (à lancer manuellement et avec parcimonie pour cette dernière), l’espace disque final que va permettre un système de fichiers en Btrfs sera bien plus optimisé et plus “grand” qu’avec du ext4
#28
Un (bon) admin de (gros) système critique 24⁄7 (genre cloud, ferme de rendu, serveur hpc, etc…) pourrait avoir besoin de planifier de la façon la plus précise possible ses besoins en mémoire de masse, non ?
Ne vaudrait-il pas mieux, dans ce cas, prévoir des racks “externes” de HDD / SSD spécialisés dans la prise régulière de snapshots + somme de contrôle + (éventuellement, c’est juste une suggestion) sauvegarde des certificats de sécurité et id+pass des users, et réserver les unités principales uniquement pour les datas / bdd / applications ?
Dans le cas d’une utilisation banale de type “poste de travail individuel”, cela signifierait au minimum deux unités de SSD, voire trois ou quatre si on envisage une configuration RAID.
Est-ce que ce genre de séparation nette des tâches (data / applis d’un côté, sécu+backup de l’autre), sans forcément utiliser un RAID, est possible avec les fs actuels ?
Pardon si cette question de néophyte enfonce des portes déjà ouvertes depuis longtemps…
Je me demandais simplement si on pouvait rendre les choses bien plus prévisibles (et donc planifiables) qu’elles ne le sont déjà, en diminuant au maximum les incertitudes, dans un système complexe, ou pas, mais dont la fiabilité est critique.
#29
Encore un super article, merci Vincent !
#30
C’est XFS qui gagne le plus de terrain au final. Il a la stabilité, la performance et les outils pour gérer tout ça sans difficultés.
La seule spécificité de BTRFS c’est les snapshots qui sont très peu utilisés en dehors d’usages spécifiques.
#30.1
btrfs gère aussi le bitrot
#30.2
Quelles sont les avantages d’un XFS par rapport à ext4 ? La seule fois où je l’ai utilisé c’était pour des I/O parallèles sur des disques. Et avec les SSD, je sais pas si XFS a toujours cet avantage.
#30.3
En gros, performances, meilleure capacité à évoluer (par exemple pas de plafonnement des inodes), quotas.
Quand tu plafonnes au niveau des inodes en ext4 parceque ton volume a trop grandi mais que ton nombre max d’inodes (qui est fixé définitivement à la création du FS) est resté le même, ce n’est jamais amusant… XFS évite cela.
Les quotas sont assez intéressants aussi, ça permet d’éviter de retomber dans une micro-gestion de plusieurs partitions distinctes pour éviter qu’un répertoire ne bouffe tout l’espace commun (pratique pour des grands espaces nas)
#30.4
Yep, je vois. Merci !
#31
J’imagine que tu fais référence au fait qu’un disque que l’on pourrait croire (presque) plein ne l’est en fait pas tout à fait ?
Mais je ne vois pas en quoi ça pose problème, du moment que le FS est “conservateur” dans l’estimation de l’espace restant en ne donnant que l’espace réellement libre sans tenir compte de la compression.
Le fait que la compression fasse qu’il se rempli bien moins vite qu’un FS classique de type ext4 n’est AMHA qu’un avantage.
Et puis puisque tu fais aussi référence à des admin de gros systèmes a priori sur lesquels plusieurs utilisateurs travaillent, il y a aussi plein d’autres paramètres qui peuvent amener des incertitudes quant au remplissage plus ou moins rapide du stockage, sans tenir compte du fait qu’en voyant la jauge atteindre les 100% un admin peut aussi faire le ménage (déduplication ou destruction des fichiers inutiles) pour libérer de la place.
Bref, à moins ne pas avoir compris, je ne vois pas bien quel pourrait être le souci.
#32
Je voulais dire que, pour mieux estimer l’espace libre à un instant T, une solution serait de répartir toutes ces fonctions des fs sur plusieurs unités physiques : une par fonction.
Par exemple, et après réflexion, il y aurait une unité pour les datas, une unité pour les snaps, une unité pour le (dé)chiffrement, une unité contenant les sommes de contrôle (CRC) de tous les fichiers + le journal + les ACL etc… Ces unités pourraient bien sûr être doublées, triplées (en raid ou pas)… pour augmenter encore la fiabilité.
Comme dit plus haut, sur un ordi perso cette configuration serait difficilement envisageable, dans ce cas prévoir ne serait-ce que deux unités serait un bon début… Non ?
Désolé si c’est une idée stupide…
#33
BTRFS possède-t-il une option type “flux d’intégrité” comme ReFS (contrôle regulier du checksum et rétablissement de la données corrompue par un éventuel bitrot en cas de RAID 1 logiciel) ?
#33.1
C’est un process offline à faible priorité (scrub) à lancer périodiquement par le scheduler, il répare les données si il y a redondance (double copie ou raid).