Sommaire
Je suis…
… un système de fichiers, encore considéré par beaucoup comme expérimental dix ans après le début de mon développement, Red Hat m’a déprécié tout récemment, une seule distribution — openSUSE — a osé me placer comme système de fichiers par défaut, mais ses utilisateurs me rejettent et me préfèrent ext4, je suis, je suis ?
- …
- Btrfs !
Présenté comme ça, ça ne donne pas très envie. Mais, pas de bol, c’est pourtant ce truc qui m’intéresse en ce moment et c’est ce dont je vais vous parler maintenant.
Voici donc l’épisode 0 de « Btrfs et openSUSE », une série de journaux sur le système de fichiers Btrfs, basée sur ma propre expérience d’utilisateur d’openSUSE. Ce qui, je vous l’accorde, n’est pas très rassurant. :-) Dans cette série, il y aura :
- des généralités sur Btrfs ;
- des noms qui pètent : sous‐volumes, snapshots, rollbacks ;
- du snapper ;
- du GRUB ;
- de la mise à jour incrémentale ;
- des quotas ;
- de la maintenance ;
- des trucs spécifiques à openSUSE ;
- des tentatives désespérées pour rester applicable à d’autres distributions ;
- des erreurs (pas taper) ;
- des bogues ;
- des cris ;
- des larmes ;
- et bien plus ! Ou bien moins.
Btrfs : l’ex‐fs du futur
Juste pour vous résumer rapidement ce qu’est Btrfs — du moins ce que j’en comprends.
tl;dr — Btrfs est un système de fichiers basé sur un arbre B et la technique du CoW ; il offre des fonctionnalités nouvelles (comparé à notre bon vieux ext4).
Arbre B
Je vous invite à lire son article sur Wikipédia. En gros, c’est simplement un arbre binaire de recherche avec des nœuds parents qui peuvent avoir plus de deux nœuds enfants.
Voici un joli schéma :
(r = racine, k = clé, c = enfant)
Je vous avais dit qu’il était beau !
Bon, vous allez être déçu — ou pas : je ne vous en dirai pas plus. Je ne vous parlerai pas non plus de son implémentation dans Btrfs. Parce que je n’y connais rien, certes… J’ai quand même pensé à vous et j’ai mis des liens plus bas qui pourront assouvir votre soif de connaissance. ;-)
Avantage : certaines opérations — dont la vérification du système de fichiers — sont rapides.
Inconvénient : il faut équilibrer l’arbre régulièrement (maintenance). FAQ Btrfs sur l’équilibrage
CoW : Copy‐on‐Write
______________________________
/ ____________ \
| < cowception > |
| ------------ |
| \ ^__^ |
| \ (oo)\_______ |
| (__)\ )\/\ |
| ||----w | |
| || || |
\ /
------------------------------
\ ^__^
\ (oo)\_______
(__)\ )\/\
||----w |
|| ||
Qu’est‐ce don’ ?
Quand on crée de nouvelles données, on les écrit sur un espace libre et on marque les métadonnées comme étant du CoW.
Quand veut modifier les données :
- on voit dans les métadonnées que c’est du CoW ;
- au lieu d’écraser directement les données qui diffèrent, on les écrit sur de l’espace libre ;
- on met à jour les métadonnées pour pointer vers les nouvelles données
Lazy copy
Le Copy‐on‐Write, c’est pratique pour faire de la copie paresseuse.
Cela consiste à ne pas vraiment copier une donnée quand on nous le demande, mais uniquement de créer des métadonnées qui pointeront vers la donnée originale. On nNécrit une donnée que quand l’original ou la pseudo‐copie commence à bouger.
Exemple de code C++
Exemple honteusement pompé sur Wikipédia :
std::string x("Hello");
std::string y = x; // x et y utilisent le même tampon
y += ", World!"; // maintenant y utilise un tampon différent
// x continue à utiliser le même tamponExemple avec Btrfs
Exemple honteusement inspiré d’un topic sur StackExchange.
Créons un fichier x et une copie paresseuse y via cp --reflink :
~# yes "hello" | head -n 1000 > x
~# cp --reflink x y
~# ls -i x y
273 x 275 y # ce sont les numéros d’inode
~# btrfs inspect-internal dump-tree /dev/vdc1
[…]
# Notre x
item 4 key (273 INODE_ITEM 0) itemoff 15889 itemsize 160
inode generation 28 transid 28 size 6000 nbytes 8192
block group 0 mode 100644 links 1 uid 0 gid 0 rdev 0
sequence 0 flags 0x8(none)
atime 1502314234.215991766 (2017-08-09 23:30:34)
ctime 1502314234.219991832 (2017-08-09 23:30:34)
mtime 1502314234.219991832 (2017-08-09 23:30:34)
otime 1502314234.215991766 (2017-08-09 23:30:34)
item 5 key (273 INODE_REF 256) itemoff 15878 itemsize 11
inode ref index 18 namelen 1 name: x
item 6 key (273 EXTENT_DATA 0) itemoff 15825 itemsize 53
generation 28 type 1 (regular)
extent data disk byte 12582912 nr 8192 # les données
extent data offset 0 nr 8192 ram 8192 # sont là
extent compression 0 (none)
[…]
# Le y a une tête similaire
item 16 key (275 INODE_ITEM 0) itemoff 14520 itemsize 160
inode generation 29 transid 29 size 6000 nbytes 8192
block group 0 mode 100644 links 1 uid 0 gid 0 rdev 0
sequence 0 flags 0x4(none)
atime 1502314493.220242255 (2017-08-09 23:34:53)
ctime 1502314493.220242255 (2017-08-09 23:34:53)
mtime 1502314493.220242255 (2017-08-09 23:34:53)
otime 1502314493.220242255 (2017-08-09 23:34:53)
item 17 key (275 INODE_REF 256) itemoff 14509 itemsize 11
inode ref index 20 namelen 1 name: y
item 18 key (275 EXTENT_DATA 0) itemoff 14456 itemsize 53
generation 28 type 1 (regular)
extent data disk byte 12582912 nr 8192 # oh ! c’est la même
extent data offset 0 nr 8192 ram 8192 # chose que x !
extent compression 0 (none)
[…]
# Un EXTENT_ITEM nous confirme qu’il y a bien partage
item 0 key (12582912 EXTENT_ITEM 8192) itemoff 16201 itemsize 82
extent refs 2 gen 28 flags DATA # Cet élément compte deux références
extent data backref root 256 objectid 273 offset 0 count 1 # 273 = x
extent data backref root 256 objectid 275 offset 0 count 1 # 275 = y
[…]
~#On voit que x et y partagent les mêmes données.
Maintenant, modifions légèrement y (rajoutons‐lui des données) :
~# yes "world" | head -n 1000 >> y
~# btrfs inspect-internal dump-tree /dev/vdc1
[…]
# On a toujours notre EXTENT_ITEM qui référence les "hello" de x et y
item 0 key (12582912 EXTENT_ITEM 8192) itemoff 16201 itemsize 82
extent refs 2 gen 28 flags DATA
extent data backref root 256 objectid 273 offset 0 count 1 # x
extent data backref root 256 objectid 275 offset 0 count 1 # y
[…]
# On a maintenant y qui commence à faire sa vie tout seul avec ses "world"
item 2 key (12591104 EXTENT_ITEM 8192) itemoff 16124 itemsize 53
extent refs 1 gen 34 flags DATA
extent data backref root 256 objectid 275 offset 4096 count 1
[…]
~# filefrag x y
x: 1 extent found
y: 2 extents found
~#x et y partagent toujours les mêmes données (les hello), mais y a un extent en plus pour les données qui lui sont propres (les world).
Maintenant créons un tout nouveau contenu pour y :
~# yes "bonjour, je suis monsieur dupont" | head -n 1000 > y
~# btrfs inspect-internal dump-tree /dev/vdc1
[…]
# C’est officiel : x est maintenant tout seul
item 0 key (12582912 EXTENT_ITEM 8192) itemoff 16230 itemsize 53
extent refs 1 gen 28 flags DATA
extent data backref root 256 objectid 273 offset 0 count 1 # 273 = x
[…]
# car y est parti
item 2 key (12627968 EXTENT_ITEM 36864) itemoff 16153 itemsize 53
extent refs 1 gen 43 flags DATA
extent data backref root 256 objectid 275 offset 0 count 1 # 275 = y
[…]
~#Avantages & inconvénients
.
Avantages :
- permettre de réaliser facilement des instantanés (snapshots) ;
- éviter la duplication de données ;
- opérations transactionnelles (la mise à jour des métadonnées est censée être atomique).
Inconvénients :
- ça fragmente.
Solutions :
- se reposer sur les stratégies de Btrfs pour limiter la fragmentation ;
- défragmenter manuellement (maintenance) ;
- désactiver le CoW pour les fichiers, dossiers et sous‐volumes qui reçoivent beaucoup d’écritures aléatoires.
Fonctionnalités
.
Maintenant qu’on a survolé les deux grands principes sur lesquels reposent Btrfs, arbre B et CoW, intéressons‐nous aux fonctionnalités offertes.
On ne va pas se casser la tête et on va piocher directement sur le wiki du projet :
- stockage de fichier basé extent ;
- taille maximale par fichier : 264 octets = 16 Eio (en pratique, la limite tombe à 8 Eio à cause du VFS de Linux) ;
- stockage efficace de petits fichiers ;
- stockage indexé efficace des répertoires ;
- allocation dynamique de nœuds d’index (inodes) ;
- sous‐volumes (sorte de systèmes de fichiers internes) ;
- instantanés en lecture seule ou en lecture‐écriture ;
- sommes de contrôle sur les données et les métadonnées (CRC32C) ;
- compression (zlib et LZO) ;
- prise en charge de plusieurs périphériques (RAID) :
- file striping (RAID 0),
- file mirroring (RAID 1),
- file striping + mirroring (RAID 1+0),
- single et dual parity (RAID 5 et 6) : expérimental ;
- pour les SSD : TRIM/Discard et optimisations ;
- sauvegarde incrémentale ;
- défragmentation à chaud ;
- vérification du système de fichiers à froid ;
- conversion de systèmes de fichiers ext3 et ext4 ;
- « périphériques graines » (seed devices), des sortes de modèles de système de fichiers, en lecture seule, que l’on peut copier sur d’autres systèmes de fichiers, si j’ai bien compris ;
- prise en charge de quotas par groupes de sous‐volumes (qgroup) ;
- envoi et réception de changements d’un sous‐volume ;
- déduplication après écriture (la déduplication à la volée est expérimentale).
Les sujets en gras seront abordés dans les prochains épisodes de la série. Les sujets qui ne sont pas en gras seront peut‐être abordés, mais rien n’est moins sûr.
J’espère que cet épisode introductif vous a plu et je vous laisse sur quelques liens.
That’s all folks!
Liens
- le wiki du projet Btrfs ;
- BTRFS: The Linux B-tree Filesystem (ACM Digital Library), O. Rodeh, C. Mason, J. Bacik, ACM Transactions on Storage, août 2013. Lien vers le texte complet disponible depuis la page personnelle d’O. Rodeh ;
- B-trees, Shadowing, and Clones (ACM Digital Library), O. Rodeh, ACM Transactions on Storage, 2008. Lien vers le texte complet disponible depuis la page personnelle de O. Rodeh.
# Quelques précisions
Posté par SaintGermain . Évalué à 6.
Merci d'essayer de clarifier Btrfs pour le commun des mortels, ce FS en a bien besoin.
Quelque commentaires :
[^] # Re: Quelques précisions
Posté par Manozco . Évalué à -10.
Au risque de paraître tatillon, ZFS n'a pas de problème de licence, c'est le noyau Linux qui en a un (et plus globalement la GPL/ le projet GNU ) :)
Il semblerait d'ailleurs, vu les mouvements de Canonical avec l'inclusion d'OpenZFS par défaut sur les noyaux Ubuntu qu'il n'y ait aucun problème de licence.
[^] # Re: Quelques précisions
Posté par SaintGermain . Évalué à 4.
ZFS est sous licence CDDL et Linux sous licence GPL. Il n'y a aujourd'hui pas d'avis unanime à propos de la compatibilité entre les deux licences, d'où le problème.
Aucun problème de licence, circulez il n'y a rien à voir : nier le problème comme cela est sûrement très constructif pour faire avancer les choses.
Je préfère donner un lien vers Wikipedia qui résume bien la situation : https://en.wikipedia.org/wiki/ZFS#Linux
[^] # Re: Quelques précisions
Posté par Zenitram (site web personnel) . Évalué à -3. Dernière modification le 15 août 2017 à 08:41.
Perso, je trouve dommage qu'ils ne passent pas à GPLv3.
En effet, ça aurait été "rigolo" que les pro-GPL se retrouvent avec 2 gros morceaux intéressants en GPL (donc qu'ils aiment à fond, pour les deux logiciels) mais qu'ils soient incompatibles :).
Avec la CDDL, on reste entre deux eaux (pas manifeste que ce soit non légal ou légal, et pas "tamponné FSF", zut)
Disons que les temps changent, la période de "je te fais peur" devient longue, qu'il y a plus d'1 an il y a une entité pas pauvre ("bankable") et pas non connue ("ça se sait") qui a osé défier la FSF sur leur analyse de la chose en estimant qu'il n'y avait pas de problème d'après leur lecture, et depuis la FSF n'a pas réagi. A un moment, on se dit que ceux qui disent qu'il y a un problème de légalité mais qui ne demandent pas à un juge de confirmer leur lecture sont comme SCO (ils FUDent). La FSF s'est mise dans une position qui ne peut que la rendre non crédible, à accuser sans demander qu'un tiers (un juge) valide cette accusation (et ce ne sera pas la première fois), et ça ne va pas aider pour la réputation des développeurs qui choisissent la GPL (on sait qu'on peut à tout moment être accusé gratuitement de violer leur licence et donc se prendre du troll sans que cette accusation ne soit "challengée" devant un tiers, ça devient de plus en plus un critère négatif quand on veut faire autre chose qu'utiliser le logiciel comme si on avait du proprio).
[^] # Re: Quelques précisions
Posté par SaintGermain . Évalué à 3.
Si ZFS passent à GPLv3, Linus serait peut-être prêt à faire passer le noyau en GPLv3 ? ;-)
Bon c'était sans doute pour rire (mais on ne sait jamais avec ce Linus).
Un an ce n'est pas très long, quand on voit le temps que cela a pris pour SCO vs Linux (qui est toujours devant les tribunaux d'ailleurs).
C'est à partir du moment où on aura le cas devant un tribunal que cela va devenir intéressant.
[^] # Re: Quelques précisions
Posté par Psychofox (Mastodon) . Évalué à 2.
Est-ce qu'il est inclu sous forme binaire ou compilé à chaque installation/maj. Ça change tout du point de vue respect de la licenve.
[^] # Re: Quelques précisions
Posté par AR7 (site web personnel) . Évalué à 1.
Oui, tu as raison, c'est sans doute plus clair comme ça :-)
J'ai essayé de donner une définition générale, inspirée entre autres de ce passage du wiki Btrfs, pour ne pas avoir exactement la même définition que pour la copie paresseuse. Mais au final, c'est du pareil au même.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -7. Dernière modification le 15 août 2017 à 14:56.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Quelques précisions
Posté par ylsul . Évalué à 2.
Je ne comprends pas la distinction que tu fais : il me semble que tu décris simplement les deux étapes du même fonctionnement, non ?
La copie sur écriture / différée fonctionne comme ça :
Bon, là ce serait plus facile à comprendre avec un dessin… en gros je veux une copie modifiée d'un arbre (un nœud remplacé), je dois faire une copie de ce nœud et de tous ses nœuds ancêtres, jusqu'à la racine ; ce nouvel arbre a une nouvelle racine, les nœuds sur la branche recréée peuvent référencer aussi d'anciens nœuds dans l'arbre. L'ancien arbre n'a pas été modifié (la racine pointe toujours vers le même arbre, exactement), la nouvelle racine référence un arbre constitué d'anciens et de nouveaux nœuds.
Pour l'implémentation dans Btrfs je ne connais pas les détails par contre…
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Quelques précisions
Posté par SaintGermain . Évalué à 1.
J'avoue que je ne comprends toujours pas la différence entre CoW et la copie paresseuse.
Sur Wikipedia, le CoW est décrit ainsi :
Ce qui me semble être en phase avec ce que j'ai écrit :
Si quelqu'un pouvait éclairer ma lanterne ?
Merci
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -5. Dernière modification le 15 août 2017 à 18:17.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Quelques précisions
Posté par Yves (site web personnel) . Évalué à 3.
La différence se joue ici : « Modifications must still create a copy » / « lorsque B est censé être modifié ». La modification peut intervenir sur A ou B, comme indiqué par Zino. Toi, tu ne parlais que d’une modification sur B.
[^] # Re: Quelques précisions
Posté par Kerro . Évalué à 2.
Avec ZOL non plus. C'est l'implémentation « officielle » de ZFS sur Linux et ça passe crème au niveau licence (voir la FAQ).
# tout compris
Posté par afby . Évalué à 3. Dernière modification le 15 août 2017 à 09:08.
Enfin presque ! :)
Il y aura un chapitre sur la récupération de données,ce genre de choses ?
Merci
[^] # Re: tout compris
Posté par AR7 (site web personnel) . Évalué à 3.
Ce n'est pas prévu pour l'instant. Mais je prends note, ça peut être intéressant.
Avec plaisir ;-)
# Fragmentation: encore un problème sur SSD?
Posté par THE_ALF_ . Évalué à 5.
Est-ce que la fragmentation est encore un problème sur les SSD, vu qu'il n'y ne devrait pas y avoir de différence pour accéder aux données, qu'elles soient physiquement proches ou éloignées (contrairement aux HD)?
Est-que cette vision est trop naïve? Y-a-t il des benchmarks montrant au cours du temps une perte de performance de BTRFS liée à la fragmentation quand utilisés sur HD ou SSD?
[^] # Re: Fragmentation: encore un problème sur SSD?
Posté par ckyl . Évalué à 7.
Je pense qu'il y a un gros mythe sur les SSD venant de la lenteur absolue dans seek HDD. Une lecture aléatoire sur un SSD reste un ou deux ordres de grandeur plus lente qu'une lecture séquentielle (Si tes blocs sont suffisamment gros, genre quelques MB, entre les seeks alors ça peut se masquer pour arriver à 25..50% de perte).
Pas de réponse à ta question sur btrfs. Peut être que ça fragmente suffisamment peu pour qu'on puisse l'ignorer mais autrement une lecture séquentielle est toujours préférable (ça vaut aussi pour la RAM et à peu près tout).
[^] # Re: Fragmentation: encore un problème sur SSD?
Posté par xcomcmdr . Évalué à -1. Dernière modification le 15 août 2017 à 11:50.
Défragmenter des fichiers sur un SSD est inutile, à part pour réduire artificiellement sa durée de vie.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Fragmentation: encore un problème sur SSD?
Posté par deuzene (site web personnel) . Évalué à 4.
T'as des preuves/sources pour étayer ce que tu dis ? Ou c'est une croyance personnelle ?
« Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »
[^] # Re: Fragmentation: encore un problème sur SSD?
Posté par xcomcmdr . Évalué à 1.
Fait : Les SSD sont infiniment moins gênées par des données non-séquentielles, car ils ne sont pas des disques durs.
Ce qui rend la défragmentation inutile.
Fait : Le support de stockage utilisé par les SSD ont un nombre limité d'écritures avant d'être kapout.
Ce qui rend la défragmentation dangereuse.
Fait : Un contrôleur SSD essaie de gérer la durée de vie ses blocs de manière uniforme. Pour éviter que certains deviennent kapout alors que d'autres étaient "comme neufs". Donc évidemment, les données vont être fragmentées.
Ce qui rend la défragmentation idiote.
D'autres questions ?
Ils ne sont pas non plus en bois, ni en poivre, ni en carton, ni en poudre verte, ni en gélules, ni en gel, ni en viande, ni en eau, ni…
Mais j'avoue avoir du mal à voir le rapport entre le sucre et les SSD.
Peux tu éclairer ma lanterne ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Fragmentation: encore un problème sur SSD?
Posté par Kerro . Évalué à 7.
Cette fragmentation n'est pas visible par le système de fichiers. Ce n'est pas la fragmentation dont on parle ici.
De plus c'est fait uniquement par bloc entier de cellules du SSD (à ma connaissance), donc ça ne perturbe en rien les accès en lecture ou en écriture.
La fragmentation ne tombe pas forcément (voir même rarement ?) sur une frontière de bloc de cellules de SSD. Donc il y a une perte de temps (un peu en lecture, beaucoup en écriture), et éventuellement gaspillage de cache interne du SSD. Je n'ai jamais fait de mesure, donc je ne sais pas quantifier.
Mais surtout beaucoup de SSD (ou même tous ?) sont bien plus lents en lecture aléatoire. Du genre 3 fois plus lents sur certaines charges, même avec des lectures alignées sur 4k (Samsung 840 pro par exemple, qui n'est pas un modèle d'entrée de gamme).
Tu trouveras des infos à ce propos sur plein de sites de gaming.
[^] # Re: Fragmentation: encore un problème sur SSD?
Posté par xcomcmdr . Évalué à -3.
Oui c'est ce que j'ai vu. Donc une défragmentation au niveau du FS est encore plus inutile.
Mauvais SSD, changer SSD (ce que j'ai fait).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Fragmentation: encore un problème sur SSD?
Posté par flan (site web personnel) . Évalué à 5.
Ton implication est fausse. La défragmentation est donc moins utile. Tout est de savoir dans quelle mesure !
Ton implication est encore fausse : pour ça, il faudrait savoir de combien elle réduit la durée de vie du SSD. Si c'est de 0,001%, on peut la considérer comme indolore.
Ton implication est encore fausse. La fragmentation du SSD n'a pas lieu au même niveau.
[^] # Re: Fragmentation: encore un problème sur SSD?
Posté par xcomcmdr . Évalué à -9.
LinuxFR défragmente des SSD.
Putain la honte.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Fragmentation: encore un problème sur SSD?
Posté par xcomcmdr . Évalué à 2.
Source (parmi beaucoup d'autres) : https://blog.oo-software.com/en/defragmentation-and-ssds-opportunities-and-risks
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Fragmentation: encore un problème sur SSD?
Posté par claudex . Évalué à 2.
Pourtant, le random read est clairement moins bon que du séquentiel http://ssd.userbenchmark.com/Samsung-850-Evo-250GB/Rating/2977 ou http://ssd.userbenchmark.com/Intel-520-Series-120GB/Rating/1935 C'est bien que la fragmentation n'est pas si bien que ça.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Fragmentation: encore un problème sur SSD?
Posté par Crao . Évalué à 7.
Ce que tu n'as pas l'air de comprendre c'est que tu n'as pas la moindre idée de la fragmentation interne du SSD. Entre ce que pense être l'organisation des données sur le disque pour le système d'exploitation et l'organisation réelle des données dans les puces c'est complètement différents, et il n'y a aucun moyen de savoir comment c'est dans le SSD. De plus chaque contrôleur SSD aura sa propre stratégie.
Il y a également des tas de SSD qui ont un "cache" avec de la flash SLC, et les données dans ce cache seront ensuite écrite en arrière plan dans la flash TLC. Il y a également les algo de wear leveling qui vont réorganiser en arrière plan les blocs de flash partiellement utilisés en blocs complètements utilisés (la commande trim aidant le SSD à connaitre les emplacements libres) pour avoir plus de blocs libres et de meilleurs performances en écriture dans le futur en évitant le phénomène de write amplification.
À partir de là tu devrais commencer à comprendre que défragmenter un système de fichier sur un SSD va entrainer, d'une part une usure inutile des cellules flash, et d'autre part une désorganisation interne des blocs flash. Tout le boulot fait par le SSD pour conserver son endurance et ses performances va être saccagé par les tonnes d'écriture faite par le processus de défragmentation et consolidation du système de fichier.
Un disque SSD ne fonctionne pas du tout comme un disque dur, et donc il ne faut surtout pas utiliser les mêmes stratégies.
[^] # Re: Fragmentation: encore un problème sur SSD?
Posté par claudex . Évalué à 2.
Sauf que les cellules d’un SSD, elles font plus que 4k, donc si tu fragmentes ton FS, tu vas avoir plusieurs fichiers différents par cellule du SSD, et c’est ça qui va te tuer le plus les perfs. Donc, oui, la fragmentation est inévitable mais sur des blocs de taille différents que le FS.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Fragmentation: encore un problème sur SSD?
Posté par freem . Évalué à 4.
Question: c'est quoi la taille d'une cellule de SSD? Enfin, je veux dire, c'est de quel ordre de grandeur? Parce que du coup ça pourrait p'tet être intéressant de configurer le FS pour que la taille d'un bloc soit plus proche de la taille d'une cellule du SSD?
Je sais que du coup on perdrai de l'espace pour les petits fichiers (genre ceux dans /etc) mais dans le cas des fichiers de, genre, /usr/bin ou /var/cache/apt/archives, c'est moins sûr…
J'imagine que c'est une question bête, dans ce cas mea culpa :)
[^] # Re: Fragmentation: encore un problème sur SSD?
Posté par claudex . Évalué à 3.
Ça dépend des modèles, les pages (la plus petite quantité inscriptible/lisible) font entre 2K et 8K, les blocks (la plus petite quantité effaçable, et donc la partie qui va être balancé sur tout le disque pour répartir les écritures) font entre 512K et 8M.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Fragmentation: encore un problème sur SSD?
Posté par BAKfr . Évalué à 2.
En fait, il y a plusieurs niveau de découpage.
Note que ces infos datent d'il y a quelques années maintenant et concernent les mémoires de type NAND. Je ne suis pas sûr que les autres technologies utilisent le même principe, et les tailles ont peut-être changés.
Je sais que j'avais lancé des benchmarks sur une carte SD "rapide", et lire 1024 octets prenait 20 fois plus de temps si les données étaient sur deux segments, par rapport à si elles étaient alignées.
[^] # Re: Fragmentation: encore un problème sur SSD?
Posté par Crao . Évalué à 2.
Oui, je n'ai jamais dit l'inverse.
Ce qui tue les perfs en lecture c'est de balancer au SSD des tonnes d'ordres de lecture de toute petite taille. Soyons réaliste, la fragmentation d'un fichier n'est vraiment un problème que pour les gros fichiers, et les gros fichiers sont très rarement voir jamais fragmentés en morceaux de 4 kio dans tous les coins du système de fichiers. Si on en arrive là c'est que la partition est pratiquement pleine et il va y avoir beaucoup de problème bien plus important que la vitesse de lecture aléatoire de blocs de 4 kio sur le SSD.
En pratique qu'un gros fichier soit un peu fragmenté au niveau du système de fichier n'aura aucun conséquence visible sur les performances.
[^] # Re: Fragmentation: encore un problème sur SSD?
Posté par claudex . Évalué à 5.
Ce qui est dit depuis le début, c'est que la lecture aléatoire est plus coûteuse qu'une lecture séquentielle, sans inférer que ça avait un impact visible, juste qu'au niveau benchmark c'est très visible et donc pas forcément négligeable. Et que potentiellement, Btrfs ne fragmente pas assez pour que ça ait un impact (ce qui est sans doute dépendant des workload).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Fragmentation: encore un problème sur SSD?
Posté par ckyl . Évalué à 5. Dernière modification le 15 août 2017 à 13:55.
OK. Donc si on va jusqu'au bout du raisonnement, tu veux dire que si aucun bloc de ton (FS|fichier) n'est séquentiel ça ne pose aucun problème ?
Faisons un petit test sur un "vieux" SanDisk Ultra II (SDSSDHII480G) avec LVM + luks + ext4:
Lecture séquentielle: 244MB/s 60K IOPS
Lecture aléatoire: 18MB/s 4K IOPS
En fait la vraie question est comment un FS donné fragmente dans une utilisation courante / donnée ?
Sur un FS classique tel que ext4, la fragmentation est, grosso modo, liée à l'augmentation de taille des fichiers. Si le bloc suivant n'est pas libre quand tu veux faire grossir un fichier, il faut en trouver un autre autre part. Sauf cas pathologique ça fragmente assez rarement, et on peut sûrement arriver à ton raccourci (ie. l'impact est suffisamment faible pour qu'on le néglige).
Sur un FS basé sur du COW je serais beaucoup moins sur. Je ne connais rien à btrfs, mais je peux imaginer de nombreux cas d'écriture ou le COW mène à une très forte fragmentation. On retombe sur des lectures purement aléatoires… 10x plus lentes. Et c'est peut être aussi pour ça que btrsfs à un outil de defrag et une defrag online !
https://btrfs.wiki.kernel.org/index.php/Gotchas#Fragmentation
Tu me fais un test comparatif de perf ssd + btrfs avec et sans fragmentation ?
Tu me fais un calcul au dos de l'enveloppe ou une étude réelle ? Les SSD ne sont pas en sucre.
[^] # Re: Fragmentation: encore un problème sur SSD?
Posté par Zenitram (site web personnel) . Évalué à 5. Dernière modification le 15 août 2017 à 14:44.
Corrige-moi si je me trompe, mais ton test teste les accès aléatoires, avec des IO aléatoires, et donc tu testes le coût d'un accès aléatoire, alors que ce dont il est parlé est un fichier séquentiel mais dont données sont plus aléatoires dans le SSD du fait du COW (donc c'est peu de "random" d'une, car on n'a pas pour habitude de changer 100 000 fois un même fichier).
La, en imaginant la chose (donc aucun argument autre que ma tête), je me dis que ça n'a pas grand chose à voir avec ton test.
Peux-tu faire une démonstration avec par exemple la lecture séquentielle (et non randread, car on cherche l'impact du COW sur une lecture séquentielle) d'un fichier de 4 Go dont 100000 (au pif, mais 100000 changements aléatoires sur un fichier sans le réécrire complètement c'est déjà un cas d'usage peu classique voir avec une sacré marge) octets à la position aléatoires ont été modifié sur un FS supportant le COW (donc 100000x 4 KB ont été "déplacé"/fragmentés, soit 10%, amis si tu veux aller à l’extrême pourquoi pas change le 1000000x pour être, au hasard près, proche de 100%)?
(perso, je ne sais pas tester ça en moins de quelques minutes, mais suis intéressé par le résultat, par contre je sais que le randread a un impact surtout quand on n'a pas de queue mais rien de nouveau c'est testé partout lors d'un test d'un SSD; et je fantasme que lors d'un accès séquentiel sur un FS supportant le COW, le FS se ferait plaisir à détecter la demande séquentielle et ferait un autre thread qui lit en parallèle dans le cache les blocs arrivant sous peu mais déplacés, ou alors en fait le FS sait que le SSD s'en fout complet niveau perf, je ne sais pas juste suppositions)
Bref, ne faisons pas n'importe quel test au pif, mais un test qui correspond au cas d'usage débattu, et ton test ne semble pas être proche du cas débattu (ou je ne l'ai pas compris, c'est possible aussi, mais la je demande alors de m'expliquer en quoi ça correspond alors qu'il me semble qu'on met en jeu beaucoup de couches intermédiaires qui changent tout en disant que tel truc précis a un impact).
Non, mais mêmes les constructeurs n'osent pas dire qu'ils sont aussi endurant que les HDD, as-tu plus de connaissances sur le sujet que les constructeurs?
Test d'endurance SSD (oui, ça meurt un SSD plus vite si on déplace les blocs plus souvent genre si on fait des déplacements en plus comme discuté, faut pas en faire 10000 trop souvent, nombre non pris au hasard)
Sérieusement, il y a assez eu de tests d'endurance sur les SSD et de discussions sur la quantité de blocs de réserve à mettre sur un SSD pour que ta réaction sarcastiquement sucrée sur ce sujet enlève de la crédibilité sur le reste qu'on connait moins.
# Fichiers souvent modifiés et fragmentation
Posté par windu.2b . Évalué à 3.
Si je comprends bien tout à tes explications concernant le COW, chaque fois qu'un fichier est modifié, la partie nouvelle est recopiée à part, et l'ancienne est ensuite supprimée (ou plutôt, n'est plus référencée) ?
Donc, un fichier fréquemment modifié (disons, un fichier de traitement de texte ou de tableur) se retrouverait éclaté en plein de petits bouts, chacun correspondant à une sauvegarde du fichier (et oui, certains appuient sur
Ctrl+Sà chaque mot qu'ils tapent) ?Ces petits bouts recopiés ont-ils la taille d'une page du FS, ou bien juste la taille des données nouvelles (et donc les nouvelles pages du FS peuvent être très vides) ?
[^] # Re: Fichiers souvent modifiés et fragmentation
Posté par wismerhill . Évalué à 8.
Les traitements de texte et tableurs (en tout cas libreoffice, et d'autres aussi probablement) ne mettent pas à jour le fichier, mais enregistrent dans un nouveau fichier, puis renomment atomiquement en remplaçant l'ancien fichier. Donc pas de CoW puisque ce sont de nouveaux fichiers à chaque fois.
Cette façon de faire évite, en cas de plantage, de se retrouver avec un fichier corrompu (la copie en cours d'enregistrement le sera probablement, mais l'ancien fichier n'aura pas encore été écrasé), mais ça ne préserve pas les droits des fichiers (en particulier si on avait le droit d'écriture sans être propriétaire du fichier).
[^] # Re: Fichiers souvent modifiés et fragmentation
Posté par AR7 (site web personnel) . Évalué à 3. Dernière modification le 16 août 2017 à 11:12.
+1
Pour avoir testé rapidement, je n'arrive pas à fragmenter avec LibreOffice et gedit.
Par contre, pour des fichiers souvent modifiés "aléatoirement" (je pense aux vms et bases de données notamment), le CoW peut induire beaucoup de fragmentation. Cela vaut alors le coup de le désactiver. J'en parlerai dans le prochain épisode.
# Copy On Write et c++
Posté par moi1392 . Évalué à 7.
Juste pour info, l'exemple du copy on write pour les std::string en c++ est aujourd'hui faux sur la plupart des implémentations de la bibliothèque standard.
Par exemple, la libstdc++ fournie par le projet GCC a changé cette implémentation lors de la sortie de gcc 5 car elle pose beaucoup de soucis de performance à cause des protections multi thread.
# OCFS2
Posté par saltimbanque (site web personnel) . Évalué à 3.
peut être quelqu'un de plus cultivé que moi pourrait décrire les snapshots de OCFS2.
pourquoi écris-je cela : parce que 1. j'ai très souvent lu Btrfs attendu pour les snapshot, 2. visiblement OCFS2 offre des snapshots depuis longtemps.
peut être que OCFS2 pêche par d'autres aspects et que ce FS ne peut pas être par défaut,
du coup on ne peut pas se reposer sur le FS pour les snapshot.
# Erreur équilibrage arbre B
Posté par AR7 (site web personnel) . Évalué à 2.
J'ai écrit une bêtise dans la partie arbre B.
J'ai mis en inconvénient qu'il fallait régulièrement équilibrer l'arbre B. C'est faux. L'arbre B implémenté dans Btrfs s'équilibre tout seul.
[^] # Re: Erreur équilibrage arbre B
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Corrigé, merci.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.