À noter également, il est prévu de créer un outil pour faire la migration d'une partition ext4 en btrfs...
Par contre je suis navré, j'ai lu ça sur lwn.net, mais je ne retrouve plus le lien.
Je pense que c’est pas pareil, la dépêche de Patrick_G parlait des systèmes de fichier pour écrire directement sur la mémoire flash, sur les SSD il y a une couche d’abstraction matérielle.
Et je crois que tout les SSD 'hautes performances' qui sont sorti recement se comporte comme des disque(*) et qu'on utilise donc des systeme de fichier 'normaux' dessus.
*: Ce qui explique d'ailleur pourquoi ils ont parfois des performances en écritures aléatoire pas terribles ces SSD quand ils commencent a être rempli..
Pas seulement, toutes les cartes SD/CF/..., clés USB, et SSD, contiennent un FTL (en:Flash_Translation_Layer) qui les font apparaître comme un périphérique de type "bloc", c'est à dire typiquement fait pour les disques durs et autres périphériques magnétiques. Bref, c'est complètement inadapté (il vaudrait mieux pouvoir y accéder comme un périphérique MTD (en:Memory_Technology_Device)) mais c'est comme ça. Et donc on ne peut (enfin, on pourrait, mais il vaut mieux pas) que utiliser des FS faits pour les disques.
Il serait toujours possible de faire du wear leveling en évitant d'écrire toujours les mêmes blocs.
Les SSD ont un autre énorme problème : la taille du bloc d'écriture. Il fait autour de 128Ko. Une écriture de 1 octets provoque une écriture de 128Ko. L'effet est d'avoir une vitesse d'écriture aléatoire de petit bloc très très lente. Certain SSD tombe à 4 écritures/s pour des blocs de 4ko, soit une latence de 250 ms ! On est loin des 0.1 ms promis !
Les 2 techniques pour limiter cette effet est la multiplication des "channels" de mémoire flash sur le contrôleur (4 chez certain, 10 pour celui d'intel) et l'ajout de mémoire cache SDRAM (j'ai déjà vu 32Mo).
Cette lenteur est très visible lors de la décompression d'un gros tar ou la copie de répertoire. La vitesse de décompression d'un noyau pourrait être un bon bench :)
Heu, il me semble que tu fais une petite erreur, on est obligé d'effacer un erase block si on veut écrire dans un endroit déjà écrit auparavant, en effet. Mais une fois que cette zone a été effacée (128Ko c'est pour donner un ordre d'idée je suppose, mais ça doit être à peu près ça), on peut y écrire en plusieurs fois, par page de 4 ou 8Ko environ (encore variable selon les technos/constructeurs/...), jusqu'à la remplir. Sinon ce serait vraiment la galère.
Sinon, pour les problèmes de perf, je pense aussi que les algos de wear-leveling jouent beaucoup sur la lenteur : si c'est un algo merdique (vu comme le domaine doit être blindé de brevets, aussi ...), le fait d'écrire plein de petits blocs va vraiment le faire ramer. Ça plus les problèmes d'erase block, effectivement ça ne donne pas un joli résultat.
Enfin, en ce qui concerne la SDRAM, j'avais lu qu'elle ne servait pas de cache, mais de mémoire "opératoire" pour le chip qui fait le wear-leveling ; il y stocke diverses infos pour faire ses calculs, mais ce n'est pas un cache de données (à vérifier).
Enfin bon, comme d'hab, dans un domaine ou les constructeurs sont peu bavards, on ne peut pas faire mieux que de spéculer ...
Mais une fois que cette zone a été effacée (128Ko c'est pour donner un ordre d'idée je suppose, mais ça doit être à peu près ça), on peut y écrire en plusieurs fois, par page de 4 ou 8Ko environ (encore variable selon les technos/constructeurs/...), jusqu'à la remplir. Sinon ce serait vraiment la galère.
Cela explique la chute de perf quand le SSD se remplit. D'après les white paper de samsung (?), ils agissent par bloc de 4Mo, dans lequel il font "tourner" les blocs. donc, si on écrit beaucoup dans un bloc de 4Mo, il tourne beaucoup, et il y a plus d'effacement/écriture.
Nan, les 4Mo c'est la taille de la zone sur lequel il wear-level. Tu écris par page ou bloc (ça dépend de la terminologie) de 4Ko environ, mais tu dois effacer par erase block de 128Ko environ, et la carte (puisque dans le white paper on parle de carte CF il me semble) wear-level par zone de 4Mo environ (tous ces chiffres doivent varier en fonction du constructeur, de la techno et de la taille de la carte).
Même pas, puisque les cartes flash gardent de coté des blocs de secours en cas de défaillance de certains. J'ai réfléchi à ça car je compte utiliser des CF comme disque principal, mais c'est assez chaud d'imaginer un "bench" qui permetterai de connaître les caractéristiques de la carte (j'ai déjà vu un mec faire ça, mais j'ai perdu le lien ...)
Je ne voix pas en quoi les blocs de secours entre en jeux. Ils ne sont là qu'en cas de défaillance, et ne rentre en jeu qu'en cas de soucis. Je n'imagine pas faire un teste de robustesse :)
Quel information de performance manquerait avec un "time tar xzf" en boucle jusqu'à remplissage de la partition ?
Le fait que les supports SSD sont tous en mode FTL et non en MTD ne serait-il pas dû à un OS massivement majoritaire qui a tendance à imposer sa vision des choses et qui ne sait déjà pas gérer beaucoup de FS, alors lui demander de savoir gérer un périphérique autrement... ?
(vraie question, avec quelques morceaux de trolls dedans quand même)
Oui, c'est clair que comme d'hab ce n'est pas MS qui va faire avancer les choses dans le sens des technologies futures ouvertes pour tout le monde (je les aurai bien vu sortir un truc rien qu'à eux .... tiens, d'ailleurs, voir les actus récentes sur l'ExFAT, le FS standard sur les nouvelles cartes SDXC, utilisable uniquement avec Vista SP1 ...). Et que tant qu'il ne se décident pas à bouger, personne ne le fera (enfin si, les libristes, mais tout le monde va encore leur rire au nez).
Par contre, le fait de réutiliser les connexions standards des périphériques magnétiques (ATA et SATA) est quand même un gros avantage, en ce qui concerne les standards matériels.
FTL et MTD ne sont pas vraiment des "modes". FTL c'est le nom de la puce (ou du mécanisme) qui traduit les commandes reçues, spécifiques au périphériques de type "bloc", en quelque chose qui va écrire sur les puces NAND.
Et MTD c'est le nom, sous linux, qu'ont les périphériques NAND qui sont accessibles par leur interface "native" : on ne peut pas choisir d'écrire un bloc au hasard, il faut effacer un erase block si quelque chose avait été écrit auparavant. Et le soft doit aussi gérer lui-même le wear-leveling : c'est un peu demandeur en ressources, mais ça permet de choisir _sa_ technique, et surtout d'évoluer au rythme su soft, et pas du hard.
Dommage que la Flash ne soit accessibles directement comme ça que sur les périphériques embarqués à mémoire inamovible.
PS: il n'existe pas aujourd'hui à ma connaissance de connexion matérielle standard pour relier de la Flash à un ordinateur. C'est con...
>>Dommage que la Flash ne soit accessibles directement comme ça que sur les périphériques embarqués à mémoire inamovible.<<
Ce qui est curieux c'est que la Flash ne fournisse pas les deux modes, disque dur pour la compatibilité et 'natif' pour les performances, j'imagine que les quelques cents d'Euros en couts supplémentaire pour le contrôleur doivent être considéré comme inutile..
>>PS: il n'existe pas aujourd'hui à ma connaissance de connexion matérielle standard pour relier de la Flash à un ordinateur. C'est con...<<
Bin c'est surtout récent cette mode d'avoir des 'disques Flash' donc c'est normal de réutiliser l'existant (SATA / PATA)..
Mais on peut espérer qu'à terme les connexions soit directement sur du PCIExpress..
Ce qui est curieux c'est que la Flash ne fournisse pas les deux modes, disque dur pour la compatibilité et 'natif' pour les performances, j'imagine que les quelques cents d'Euros en couts supplémentaire pour le contrôleur doivent être considéré comme inutile..
Heu ... le plus gros problème, c'est que le protocole ATA (et donc SATA) n'est simplement pas fait pour les périphériques non-"block". Ce n'est pas géré dans le protocole, donc ça ne peut pas être géré par le SSD.
Alors après, comme toujours, on pourrait inventer un petit "hack" pour faire passer des commandes MTD classiques par de l'ATA, mais à ma connaissance ça n'a jamais été fait.
Mais on peut espérer qu'à terme les connexions soit directement sur du PCIExpress..
Il faut voir ce que tu veux dire par "PCIExpress", parce que mettre une NAND connectée à du PCIe, ça veut mettre un contrôleur qui utilisera un certain protocole de communication avec l'hôte. Et pour que ce soit pas le bordel, il faudrait que ce protocole soit standarisé. Vu comme est partie l'industrie (i.e. pas dans cette voie, à part quelques exceptions), je ne pense pas que ça arrivera (tous ceux qui voudraient s'y lancer aujourd'hui auront quelques bons wagons de retard sur la concurrence si leur truc ne marche pas "out of the box").
>>Alors après, comme toujours, on pourrait inventer un petit "hack" pour faire passer des commandes MTD classiques par de l'ATA, mais à ma connaissance ça n'a jamais été fait.<<
Oui, c'est a ça que je pensais comme type de bidouille, c'est quand même un peu rallant de faire d'avoir des perf en écriture aléatoire sous-optimale a cause de limitations dans le micro-contrôleur qui gere le SSD alors que le CPU pourrait aider..
D'un coté, il n'a pas complètement tort, ça permet d'abstraire les différences du hard, et de mieux optimiser le wear-leveling en fonction du matos particulier, même si je trouve sa comparaison avec la DRAM un peu foireuse, vu que ce que fait le contrôleur de la DRAM est très basique par rapport à ce que doit faire le contrôleur de la NAND.
Mais bon, dire qu'on devrait plutôt ne pas acheter le mauvais matos, c'est facile à dire mais pas à faire : en gros, on doit éviter _toutes_ les cartes SD/CF/... qui ont toutes du wear-leveling pourri, et quasi tous les SSD saufs peut-être ceux d'Intel. Ça limite quand même beaucoup le choix ...
Sinon, moi la chose qui me plaisait dans le "raw access" à la flash, c'est le coté on est libre de wear-leveler comme on veut.
Serait-ce un concurrent sérieux de Reiserfs ? http://en.wikipedia.org/wiki/Namesys
On retrouve par exemple dans Btrfs une gestion performante des petits fichiers et d'autres caractéristiques de Reiserfs. Actuellement, reiserfs est mon système de fichier préféré mais au vu des caractéristiques de btrfs, il se pourrait bien que je change ma préférence.
J'ai une photo de Hans Reiser sur http://pjarillon.free.fr/docs/la_bande_des_rmll2000.jpg
Il avait passé tout son temps avec David Axmark à ses côtés sur la photo. Ils avaient beaucoup discuté des analogies entre la gestion des transactions des bases de données et la journalisation des FS.
Je crois qu'il en est ressorti quelques progrès de part et d'autre.
Reconnaissez-vous les autres personnes de la photo ?
Si, ça a été discuté ici sur d'autres journaux et dépêche. Il a mené la police au corps pour pouvoir discuter une réduction de peine.
The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein
Oui, et de loin franchement.
Ses fonctionnalités sont déjà largement en avance par rapport à celles de reiserfs (et reprennent comme tu le signale les bonnes propriétés de celui-ci).
Le plus important (à mes yeux, concernant un système de fichier, et en comparaison avec reiserfs) est qu'il promet d'être très activement maintenu, suscitant l'intérêt vif et la participation de développeurs critiques chez IBM, Red Hat, SUSE, Oracle, Intel. Cette diversité est prometteuse, car elle signifie que bientôt chacune de ces sociétés sera capable de gérer les bugs rencontrés par ses clients, donc en mesure de proposer et supporter officiellement ce système de fichiers, de l'affiner pour ses workloads spécifiques, etc. Par contraste, reiserfs est désormais en mode "maintenance faible" chez SUSE et Mandriva, son développeur principal ne participe plus, et il n'est tout simplement pas supporté par Red Hat (autrement dit : peu de chances d'améliorations fonctionelles, désormais, à la différence de ext4, XFS et btrfs).
Une fonctionnalité bluffante pas décrite dans la dépêche, et pas faisable avec les outils actuels (LVM) : btrfs permet de faire des snapshots d'un répertoire quelconque du système de fichier (par ex. juste le /etc). D'autre part, il n'est pas nécessaire de réserver de l'espace disque dès le départ pour pouvoir faire ses snapshots (comme avec LVM). Ce sont de petits détails, mais il y en a beaucoup comme ça, et ils chacun peu, je pense, changer la vie des sysadmins :).
Pour répondre à la question de Michel plus haut :
> Par contre comment se débrouille Btrfs par rapport à la "concurrence" sur SSD ?
Pour le moment btrfs ne fait pas grand chose de spécifique pour les SSD. En pratique : la routine de recherche permettant de trouver de l'espace libre et utilisable parmi les extents alloués dispose d'un raccourcis/court-circuit dans le cas du SSD.
Mais il est prévu d'essayer de tirer le meilleur partis, de façon spécifique, des SSD, c'est d'ailleurs pour ça qu'une option de montage spécifique "ssd" est déjà intégrée.
XFS (depuis peu, et de façon encore expérimentale) et btrfs intègrent des fonctionnalités de gestion des périphériques multiples (normalement dévolues aux couches MD et LVM du noyau) précisément pour se permettre ce genre d'optimisations : en connaissant précisément la couche physique (le matériel sous-jacent), ils pourront décider au mieux de l'agencement des données. Par exemple, dans un aggrégat de disques durs et de SSD : placer les métadonnées (nécessitant beaucoup d'accès aléatoires) sur le SSD et les données dont l'accès est plus séquentiel sur disque dur, ou encore (et parce que, pour des raisons de fiabilité, btrfs permet de dupliquer les métadonnées critiques) savoir comment répartir les diverses copies sur des disques effectivement physiquement différents est difficile lorsque cette information est masquée par l'agrégation LVM ou MD.
Et aussi : btrfs (comme ZFS en fait) peut (si monté en conséquence) s'assurer de l'intégrité des données à l'aide de checksums (pour le moment, uniquement des crc32). S'il a un accès direct aux disques physiques (direct = pas déjà agrégé / masqué par une couche raid sous-jacente), il peux décider de chercher une copie en bon état du bloc concerné, puis la dupliquer de nouveau sur le disque où la copie était mauvaise (mais dans un autre bloc), voir prendre des décisions pertinentes au sujet des blocs contigus ou du disque lui-même. Un gestionnaire RAID classique, lui, ne pouvant pas accéder aux informations du fs, se contentera de mettre le disque entier offline dès qu'il détectera le problème. C'est une problématique importante, justement, pour les SSD (dont certains blocs peuvent "vieillir" sans que l'ensemble du périphérique soit à jetter), et en fait, avec les gros disques modernes (le risque d'une panne globale du disque est aussi grand qu'auparavant, mais le risque d'avoir un ou deux blocs défectueux augmente au fur et à mesure que les disques grossissent en capacité).
Ou encore : sur un système RAID classique (logiciel avec mdadm ou lvm, ou matériel), la couche RAID permet d'avoir une seule taille de stripe, définie à la construction de l'agrégat. Ce choix n'est pas optimal pour tout les cas, même lorsque le système de fichier est proprement aligné sur les stripes (par ex. avec l'option "stride" d'ext3/ext4) : les lectures/écritures séquentielles de gros fichiers bénéficient de larges stripes, tandis que les petites écritures (métadonnées, par ex.) bénéficient de petites stripes (sans quoi, les écritures successives seront mal réparties sur les divers disques physiques de l'array). Or le système de fichier dispose de ses informations (taille probable des lectures/écritures) ; il est donc en mesure de prendre de très bonnes décisions en allouant des stripes de taille dynamique selon ses besoins spécifiques.
Je signale au passage que sur ce point (la fameuse "rampant layering violation") cette dépêche est fausse.
Je suppose qu'elle a été écrite à partir de l'article de patrick_g sur Wikipédia, qui se base sur des informations juste mais datées. En pratique, Chris Mason avait l'intention d'essayer de faire un fs qui communique et délègue aux couches pertinentes (d'où le texte dans l'article de WP), mais s'est aperçu ensuite qu'il devait gérer l'essentiel dans le système de fichiers lui-même pour pouvoir exploiter de façon optimale les périphériques multiples (cf. plus haut), les snapshots, etc.
En somme, l'intention de départ était bien, effectivement, de ne pas "violer" les divers "block layers" du noyau, mais ce qui s'est réellement passé c'est que la mentalité des développeurs Linux a globalement évolué sur ce point, et que ce type de "violations" est désormais considéré comme légitime (dans une certaine mesure). Le paradigme a simplement changé, les développeurs Linux ne sont pas obtus.
Je me trompe ou bien il existe une analogie entre les disques SSD et les cartes CompactFlash et tout ce qui y est similaire? En d'autres termes, si Btrfs arrive à maturité, pourra-t'on aussi s'en servir comme remplaçant de JFFS/CFFS?
> btrfs permet de faire des snapshots d'un répertoire quelconque du
> système de fichier
Cette fonctionalité est géniale car elle va permette de faire des sauvegardes à cout CPU quasi nul. Il va être très facile de programmer des retours arrières pour tout un tas d'opération (upgrade de système par exemple). Cette fonctionalité va de paire avec le snashot de snapshot. Les possibilités sont énormes.
> Je suppose qu'elle a été écrite à partir de l'article de patrick_g sur
> Wikipédia
Je ne sais pas si Patrick a écrit la version anglaise sur Wikipedia. Je suis partis sur cette version la car je savais que pas mal de personne sauterais sur la version Française de wikpedia. Ainsi le débat n'est en que plus animé, la version anglaise étant assez différente de la version française.
Au niveau de la séparation avec la couche LVM et le fait que cette séparation ne soit pas effective, je trouve cela dommage. J'aurais préféré que le système LVM et le device-mapper soient étendus afin de pouvoir répondre aux questions existentielles des systèmes de fichier.
Sinon, je n'y connais rien en système de fichier, j'essaye juste d'être un utilisateur avertis ;-)
Sinon, il y a une "extension" a BrtFS qui me semble aussi intéressante : CRFS (Coherent Remote File System), Il s'agit en fait d'une couche réseau pour accéder au système de fichier à distance. A suivre... car je ne sais pas ce que cela apporte par rapport a du NFSv4 ou du parrallèle NFS. En tout cas, il est bien préciser que CRFS se base sur les fonctionalités de BtrFS.
"Cette fonctionalité est géniale car elle va permette de faire des sauvegardes à cout CPU quasi nul. Il va être très facile de programmer des retours arrières pour tout un tas d'opération (upgrade de système par exemple). Cette fonctionalité va de paire avec le snashot de snapshot. Les possibilités sont énormes."
On pourrait peut-être même imaginer des VCS reposant sur les snapchsots, non ?
Bon, je sais que cela induirait forcément une dépendance forte entre le soft et le FS, ce qui n'est sans doute pas recommandé... Mais l'idée ne tiendrait-elle pas la route ?
(c'est une vraie question).
Un des principes de bases d'un VCS est de pouvoir "tourner" sur plusieurs platformes donc ne relier le soft qu'a un FS sur un OS ce n'est pas très interssant (même si on peut imaginer une couche d'abstraction pour ZFS).
Sur un système centralisé (comme subversion) ca peut être utilisé sur le serveur mais il peut y avoir un risque en terme de sauvegarde. Il faut être certain que l'on pourra toujours acceder aux données dans 10,15 ou 20 ans. Je pense que ce risque est plus fort si on dépend d'un FS que d'un format de fichier indépendant.
La ou c'est plus interessant, comme indiqué plus haut, c'est la possibilité pour tout un tas de soft de proposer, facilement ,des fonctionnalités transactionnelles sans dépendre d'un DB.
Concernant Wikipedia, je me suis permis d'apporter quelques modifications (principalement snapshot-->instantanés et des corrections de grammaire).
Il reste un truc pas très joli: "Si des données sont écrites sur un bloc mémoire alors ce dernier sera copié à un autre endroit du système de fichiers et les nouvelles données seront enregistrées sur la copie au lieu de l'être sur l'original."
Je n'ai pas trouvé comment remanier la phrase.
> reiserfs est désormais en mode "maintenance faible" chez SUSE et Mandriva, son développeur principal ne participe plus,
Rhoo, il abuse, franchement... Abandonner son FS comme ça...
Ça fait des années que Reiser ne participait plus à ReiserFS, quand il a commencé Reiser4 (2004 ?) il a arreté le dev ReiserFS. C'est donc les distributions qui ont pris le relai (principalement SUSE et Mandriva, Chris Mason faisait partir de l'équipe de chez SUSE qui maintenait ReiserFS).
Ext4 est stable;
Btrfs est encore très loin de l'être !
Il faut voir Btrfs comme le futur successeur de Ext4, je ne lis pas ça dans une boule de cristal, c'est Theodore T'so, le développeur principal de Ext4 qui le dit :-) !
Stable? Quelle distrib propose ext4 en stable? J'ai installé dans Virtualbox Mandriva2009 et Suse11, et en aucun cas il n'est proposé de formater en ext4.
Ext4 est-il vraiment recommandé en production?
En fait, on en parle peu. Peut-être qu'il est stable.
On a seulement retiré le tag en cours de développement de ext4 pour le noyau 2.6.28, openSUSE 11.1 est sortie avec 2.6.27 et mandriva 2009 est en développement donc ils n'ont peut-être pas encore inclus la fonctionnalité.
« 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
Il n'y a pas vraiment de concurrence : Ext4 est une évolution d'Ext3 destiné à être employé jusqu'à ce que Btrfs soit pleinement finalisé et opérationnel.
Ted Tso, développeur principal d'Ext4, et d'autres spécialistes des systèmes de fichiers se sont mis d'accord lors du dernier workshop dédié à ce sujet pour adouber Btrfs « NGFS » : Next-Generation File System, c'est à dire le principal futur système de fichier moderne pour Linux.
Ted Tso signale également qu'il est pleinement pour l'intégration de Btrfs dans le noyau, donc a priori il ne me semble pas du tout y avoir de rivalité entre lui et son auteur, Chris Mason.
> Maintenant la question qui se pose est: Ext4 ou Brtfs ?
Comme le disent d'autres commentaires, ça sera Ext4 ET Btrfs. Comme ça a été Ext2 ET Ext3, comme ça sera et c'est maintenant Ext3 ET Ext4.
De nombreux mois, et très probablement des années, vont passer avant que Btrfs soit au point. Ext4 est déjà au point (ou plus très loins). Btrfs est le remplaçant à venir de Ext4. Ext4 roxe, donc Btrfs sortira (en 1.0) lorsqu'il roxera, qu'il n'y aura pas de régression par rapport à Ext4, qu'il sera aussi fiable et apportera son petit plus par rapport à Ext4. BtrFS a quasiment la garantit d'y arriver car nombre de développeurs Ext vont bosser sur BtrFS. Donc Ext4 va stagner et BtrFS progresser.
Je vais en froisser quelqu'uns, mais Ext* a été (et est toujours) LE système de fichier de Linux. BtrFS sera LE système de fichier de Linux.
En passant, Ext4 est dans F10 (faut ajouter "ext4" lors du boot de l'installation). Je l'utilise, rien à dire sinon que ça marche. Il sera peut-être par défaut pour F11. Il sera très probablement par défaut pour RHEL 6. Novell a abondonné Reiser(FS|4) pour Ext*. Ext4 sera par défaut dans la distribution entreprise de Novell. Ext4 répond aux besoins actuels. Ça donne du temps à BtrFS. Pas pour flémarder, mais pour innover.
Je suis un novice en système de fichier, mais il me semblait que Linux favorisait des systèmes de fichiers où la défragmentation était inutile...
Quelqu'un pourrait éclairer ma lanterne ?
> Linux favorisait des systèmes de fichiers où la défragmentation était inutile...
C'est le cas. D'ailleurs on trouve rarement des défragmenteur sous Linux.
Ici c'est de l'optimisation pour des serveurs très stressés ou +5% de performance peut être important. C'est n'est pas pour une optimisation de "desktop".
Ext4 a aussi la défragmentation à chaud.
Ext2 (et ext3, ext4) ont la réputation de ne fragmenter que peu les fichiers.
Il faut préciser qu'on partait de loin : les système de fichier MS de l'époque utilisaient une liste chaînée des blocs libres pour trouver le prochain bloc à allouer. (il prenait le premier bloc de la liste). En somme un choix aléatoire du bloc suivant du fichier !
Ext2 utilise un algorithme qui prend en compte la proximité des blocs. Ext3 et Ext4 améliorent l'algorithme d'Ext2.
Néanmoins si ton système de fichier est bien rempli, le bloc libre le plus près peut être très éloigné !
C'est dans ces cas là qu'Extn fragmentent.
Et encore une fois, il utilise un système de fichier d'avenir (exFat), ouvert au possible, sans royalties ni brevet d'une petite PME de seattle et actuellement lisible qu'avec Vista Sp1 (exit actuellement tous les autres). http://fr.wikipedia.org/wiki/ExFAT
Attend l'exfat c'est un système de fichiers magnifique, tu peux mettre les timestamps des fichiers au format UTC maintenant.... ( http://en.wikipedia.org/wiki/ExFAT )
Ça c'est de la killer feature, tous les boutonneux de linuxiens, bsdistes et autres maceux vont pleurer leur race devant ça...
Je me pose une question et la news (de qualité :-) ) n'est pas très claire sur le sujet :
Est-ce que Btrfs va rendre obsolète l'utilisation de softs comme LVM comme c'est le cas avec ZFS ?
En particulier est-ce que l'on pourra redimensionner (agrandir ET rétrécir) une partition Btrfs sans soucis et se passer de LVM pour ce genre de tâche !
Note qu'avec ZFS, tu ne peux pas agrandir ou rétrécir un volume puisqu'un volume n'a pas de taille. Tu choisis juste sa réservation et/ou son quota (bon d'accord je sais ça revient au même).
il faut préciser : on peut agrandir un zpool (ajout de devices). tous les dataset à l'intérieur de ce pool profiterons du nouveau device et pourront voir leur taille augmenter (à moins qu'un quota ait été mis en place)
Quand à la réduction d'un zpool (enlever un device du zpool), ce n'est effectivement pas possible, pour le moment....
À part la réduction à chaud, Ext3 (et 4) peut déjà faire tout ça.
Ce que chicha demande, c'est si Btrfs peut remplacer LVM, et donc offrir toutes les fonctionnalités de celui-ci, comme l'aggrégation de disques (avec possibilité de stripping) et le découpage en volumes logiques.
Pour l'instant ce n'est pas le cas, mais sait-on jamais, ça sera peut-être dans la version 1.0, pourquoi pas ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
Zut, j'ai omis sa deuxième question, à laquelle tu répondais.
Enfin, ce lien est très intéressant, ça veut dire que Btrfs sera plutôt équivalent à ZFS qu'Ext. Personnellement, je trouve un peu dommage d'outrepasser le device mapper (qui devait être me semble-t-il l'unique point d'accès au stockage dans le noyau) et d'accéder directement aux disques pour toutes ses manipulations internes.
Certes, ça doit énormément simplifier l'administration (par exemple, pas de casse-tête lors de la réduction d'un fs, où une opération par couche est nécessaire, tout en tenant compte des écarts...), mais j'aime bien l'idée actuelle des couches séparées, qui permet de faire tout et n'importe quoi (chaque élément pouvant contenir n'importe quel élément).
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
ah ce que j'ai cru comprendre, si tu veux utiliser LVM et utiliser des couches séparé tu peux. Par contre tu pourras pas demander au FS (donc dans les couches hautes) de réparer les problèmes des couches basses (vu que les couches sont séparé il n'en a pas connaissance).
Donc tu peux faire tout et n'importe quoi, mais ca te rajoutera de l'administration.
avec zfs (sous linux) c'est la meme chose, si tu veux créer un device sur un loopback par exemple, tu peux sans problème. Par contre il pourrait pas utiliser (de façon optimale tout du moins) ses algorithmes de réplication et de choix des blocs itou.
Je vous remercie à tous les deux pour vos réponses.
herodiade : c'est exactement ce que je voulais savoir. Je n'utilise LVM que pour pouvoir agrandir et réduire des partitions ext3 sans souci et jouer avec mes partitions sur un seul disque seulement (j'ai deux disques mais un groupe par disque).
Guillaume : tu réduis souvent des ext3 en dehors d'un LVM ? ça se passe bien ? si oui alors dans mon cas LVM ne sert à rien ?
tu réduis souvent des ext3 en dehors d'un LVM ? ça se passe bien ? si oui alors dans mon cas LVM ne sert à rien ?
Non, j'utilise LVM+ext3 pour les mêmes raisons que toi, à savoir réduire des fs et réallouer l'espace libre à d'autres fs, ce qui n'est pas possible sans un outil de volumes logiques (ou alors je ne sais pas comment).
J'ai déjà pu expérimenter la réduction de fs ext3 sur des partitions classiques : ça se passe bien, mais j'ai toujours une certaine appréhension. En effet, une fois que tu as réduit le fs, la méthode consiste ensuite à supprimer la partition puis la recréer avec une taille plus petite. Tu comprendras que je ne suis pas fan du fait de supprimer une partition... Et en plus, pour utiliser l'espace gagné, tu dois créer une nouvelle partition.
Finalement, la solution LVM reste la plus souple et a fait ses preuves, autant y rester pour l'instant.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
Je te remercie pour le partage de ton expérience.
Nous avons les mêmes besoins et nous utilisons LVM de la même façon pour y répondre :-)
Maintenant c'est toujours pas super clair pour moi si oui ou non je vais pouvoir me passer de LVM pour gérer mon disque. J'ai peur que non :
Cas LVM :
Si j'ai bien compris et en schématisant : LVM permet de gérer un pool de blocs et d'allouer tel ou tel quantité de blocs a tel ou tel volume logique lui-même associé à une partition. Un des intérêts c'est que l'on peut réorganiser tout ça sans perte de données.
Cas Btrfs :
Dans le cas ou j'aurais un disque avec 3 partitions Btrfs sans LVM.
Est-ce que je pourrais réduire 2 d'entre elles et en créer facilement une 4ième avec l'espace libéré ? Est-ce qu'on pourra créer une partition avec des blocs libérés un peu n'importe ou sur le disque ? Je doute fort non ?
je pense, en tout cas avec une logique pure "Zfs" , que tu ne devrais pas avoir à "réduire" et "augmenter" la taille du pool.
Tu attribue des disques à ton Zfs, et _dans_ ton fs, tu attribue ce que tu veux (quota ET réservation d'espace!) pour les fs/répertoire que tu as crée.
La facilité d'administration des fs (qui s'utilisent comme des répertoires) permet ça.
(bon par contre ça oblige l'utilisation de zfs, donc peut pas utiliser cette place pour quelque chose qui comprend pas zfs).
J'ai vu des gens s'extasier devant des portages iscsi et une solution propriétaire très cher qui permettait de "réserver" de l'espace disque et donc d'exporter des disques virtuels (par dessus un SAN) par iscsi qui pouvaient être modifié dynamiquement en taille.
Et quand je leur ais dit que je pouvais le faire pour juste le cout du hardware avec un solaris et zfs ils m'ont pas cru XD.
A priori si j'ai bien compris les messages précédents, il me semble que brtfs n'ait pas pris le même chemins que ZFS. Ils ne cherchent pas à réécrive des fonctionnalités disponibles sur une couche plus basse (LVM, MD-RAID) mais ils en tirent parti pour optimiser les fonctions FS comme la répartition des metadata sur plusieurs disques, etc.
Vraiment très intéressant cet approche que je reprochais à ZFS. J'applaudis des 2 mains.
Does the Btrfs multi-device support make it a "rampant layering violation"?
Yes and no. Device management is a complex subject, and there are many different opinions about the best way to do it. Internally, the Btrfs code separates out components that deal with device management and maintains its own layers for them. The vast majority of filesystem metadata has no idea there are multiple devices involved.
Many advanced features such as checking alternate mirrors for good copies of a corrupted block are meant to be used with RAID implementations below the FS.
Les devs sont donc conscients de l'importance de cette hierarchie des couches, mais certaines optimisations nécessitent des fonctions plus bas niveau que ne le permet celle-ci. Donc pour rester cohérent, Btrfs est développé en séparant le FS pur de la gestion matérielle, ce qui permet à l'utilisateur soit de respecter cette convention, soit de l'ignorer s'il veut profiter d'une implémentation optimale.
Autrement dit, cette approche me paraît très ouverte et pragmatique, bien plus que ton commentaire ne l'affirme. Je crois qu'on peut s'attendre à un résultat très impressionnant.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
Pardonnez-moi de diverger, siouplè, mais il y a dans cette dépêche quelques informations qui me font penser à tux3.
Je me suis intéressé à ce FS à la fin de l'année dernière, par curiosité et parce que le nom est amusant. Au début de l'année j'ai enfin pu compiler un module kernel à partir des sources récupérées sur le dépôt mercurial et copier quelques fichiers sur une partition tux3 (c'était le seul objectif fixé). La doc que j'ai trouvée était très technique et volait bien au dessus des mes simples connaissances en système de fichiers.
Pensez-vous que tux3 soit un système de fichiers qui a des chances de percer et de finir un jour à côté de btrfs, pas forcément au même niveau ? Ou alors quelques petites informations accessibles sur tux3 afin de comprendre un peu plus l'engin et, par exemple, pouvoir le comparer à btrfs si il y a moyen de faire.
Pour l'instant ext3 me convient parfaitement, c'est seulement au titre de ma curiosité maladive que je me permets de demander. :)
The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein
Pour l'utilisation bureautique (plutôt que serveur), est-ce qu'il serait possible/envisageable de disposer d'un système de snapshot dont la portée est limitée à un fichier ou un répertoire donné ?
À mon avis ce serait vraiment une fonctionnalité intéressante de pouvoir faire, dans mon gestionnaire de fichier, click droit -> créer un point de restauration ; ou encore de choisir la version actuelle de travail en un click.
Certes ça n'aurait pas la vocation à concurrencer Git (notamment du fait de la duplication totale du fichier à la création du snapshot), mais pour un utilisateur "lambda" (comme moi) ce serait une fonctionnalité intéressante.
(en fait peut être est-ce déjà dans la roadmap de btrfs, je n'ai pas vérifié l'info...)
Les snapshots par répertoires ne sont pas encore tout à fait là, mais sont au planning . Ils étaient prévus pour fin mars 2008[1], mais Mason à préféré travailler en priorité sur les éléments de bases permettant l'intégration mainline[2] (comme la capacité de gérer proprement les partitions saturées).
Cela étant, les snapshots (de tout le root fs) sont d'ors et déjà peu couteux (COW oblige).
> Le site oss.oracle.com est entièrement down pour le moment, désolé, voici une version
> en cache :
Pas de pot, je fais une dépêche la dessus et leur site est HS depuis déjà un bout de temps. Idem tout à l'heure, je n'ai pas pu mettre la référence de la partie réseau associé BtrFS.
A mon avis, on est trop nombreux à vouloir y aller ! DLFP a trop de succés !
"notamment du fait de la duplication totale du fichier à la création du snapshot"
Non justement, le fichier n'est pas entièrement recopié lors de la création du snapshot, grâce au "copy-on-write", qui crée de nouveaux blocs dès qu'un bloc snapshoté est modifié (donc tous les blocs identiques entre le snapshot et la version courante, sont en fait communs).
Et bah justement, au moment ou tu forke un fichier, dès le premier enregistrement il y aura bien duplication des données. Je ne fait pas ici allusion au snapshot d'une partition entière (certes dans le cas du snapshot d'un répertoire ta remarque se tient).
Pas forcément. comme BtrFS a un notion du bloc (les autres système de fichier aussi), alors il ne copiera que les blocks modifiés mais pas l'ensemble du fichier.
C'est exactement ce que fait LVM lors d'un snapshot.
Le COW est-il au niveau du fichier ou un à un niveau plus petit ?
Dit autrement, lorsqu'une portion d'un fichier est modifiée par COW, est-ce l'ensemble du fichier qui est dupliqué ou seulement la partie modifiée ?
Je me pose la question de le cadre de "gros" fichiers et plus particulièrement pour des images disques de machines virtuelles où les snapshot BTRFS pourraient se substituer aux snapshot de VM.
De mémoire, pour ZFS, le Copy On Write (COW) se fait au niveau bloc, donc seuls les blocs modifiés sont dupliqués. Donc oui, en cas de gros fichiers faiblement modifiés, c'est 'efficient'.
Il y a un autre souci avec le COW, qui est rarement évoqué et qui pourtant va exclure provisoirement ces systèmes de fichiers de certaines applications.
Par nature le copy-on-write defait toute stratégie d'effacement sécurisé puisque les blocs ne sont pas écrasés mais réécrits à côté. L'attitude adoptée par ZFS comme Btrfs pour l'instant, c'est "on l'a mis dans la roadmap" ; Chris Mason a déjà dit que ça serait pas dans la version 1.0 de Btrfs et que la solution qui avait sa faveur était de crypter les blocs, ainsi l'effacement sécurisé revient à jeter la clef. Cette solution pose quand même des petits problèmes, en particulier si on sait pas au départ quels fichiers devront faire l'objet d'un effacement sécurisé, il faut tout crypter - en plus pour que ça soit crédible il faut crypter sérieusement, et ça ça a un coût.
Oui, mais pour pouvoir jeter la clef, il ne faut pas qu'elle ait été stoquée sur le FS ! Ou alors il faut chiffrer cette clef pour pouvoir jeter la nouvelle clef de chiffrement pour pouvoir oublier la première clef...
StackOverflowError at Brain (unknown location)
(oui, je sais, mon cerveau a une pile *très* limitée...)
> Par nature le copy-on-write defait toute stratégie d'effacement sécurisé
> puisque les blocs ne sont pas écrasés mais réécrits à côté.
Je ne vois pas ou est le problème...
Pour vraiment effacer les données, il faut ré-écrire dessus un certain nombre de fois et non une seule fois.
Rien n'empêche d'écrire le fihcier n+1 sur l'ancien fichier n.
Mieux encore, rien n'empêche d'avoir une option de montage, du style 'secure-delete' qui écrirait dans un journal tous les block qui ne servent plus et qu'un processus parallèle de BtrFS s'occuperait en tâche de fond d'effacer entre 4 et 7 fois avec des données aléatoires.
Bref, je ne vois pas ou est la sécurité de ré-écrire au même endroit.
Heu, un secteur effacé une fois n'est plus lisible par le disque. La méthode que tu préconise (écrire plusieurs fois) n'est valable que pour les gens qui sont prêts à démonter le disque et y aller avec du matos très spécifique et très cher. La sécurité c'est une question de moyens qu'on y met, et il me semble que le but ici n'est "que" de se prémunir du cas où quelqu'un va "simplement" vouloir trouver des données non-écrasées sur le disque ...
de toute façon, ceux qui veulent vraiment conserver leur données secrete démonte le dd, le démagnétisent, le brule, puis en font de la charpie (qui a parlé de la CIA ? Xd).
Rien n'empêche de ne faire qu'une écriture. Option 'secure-delete=1' par exemple. Et puis, il peut mettre des zéro ou des chiffres aléatoire... Encore une fois, je pense que déléguer cette tâche a un processus parallèle asynchrone me semble une bonne idée.
Le problème n'est pas la méthode de réécriture pour rendre illisible les données initiales ; il en existe plusieurs et les programmes qui font se genre de chose laissent souvent le choix à l'utilisateur du nombre de passes, etc.
Le problème est que ça marche bien avec un système de fichier du type ext3 par exemple par que si tu lui dit écrase le contenu du bloc N avec ce pattern, il va effectivement écrire par dessus le bloc N qui sera ensuite illisible, l'implémentation du système de fichier n'a pas à le savoir c'est en dehors de son domaine.
Quand on utilise du COW, l'implémentation du système de fichier va écrire un nouveau bloc autre part sur le disque (ou plusieurs éventuellement dans un scénario RAID-Z et co) et marquer simplement l'ancien comme libre à la fin. Donc le secure delete a besoin d'un support au niveau du fs pour fonctionner (ce qui est un problème différent de la manière dont il est exécuté) et actuellement ce support n'existe à ma connaissance pas dans l'implémentation de ZFS, ni dans celle dans Btrfs, il est simplement "envisagé" (comme dans "on y réfléchit"). Pour l'instant le secure delete dans Btrfs ou ZFS, tintin, et il vaut donc mieux le savoir.
cela m'étonne quand même que, si la taille d'un fichier n'augmente pas, et qu'il n'est pas "protégé" (cad référencé par un snapshot, clone ou semblable), le fs va copier le bloc autre part, parce que dans ce cas la fragmentation va exploser.
EXT et BrtFS fragmentent, c'est normal pour un système si on ne veut pas perdre de place. Le problème de FAT et NTFS est qu'ils ne cherchent pas à éviter la fragmentation, en gros, on commence à mettre le fichier dès qu'on trouve de l'espace entre 2 blocs occupé et tant pis si on doit fragmenter. Tandis que EXT* (et sans doute BrtFS) essaye(nt) de trouver un espace suffisamment gros pour ne pas fragmenter le fichier mais si le fichier est trop gros, il faut le fragmenter. Il est donc tout à fait normal de pouvoir défragmenter sa partition. Par exemple, pour mon /home en ext2, il y a 4,5% de fichiers non-contigus.
« 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
A vrai dire je suis d'accord avec toi sur la FATxx mais je pense (je peux me tromper) que NTFS évite également la fragmentation (à l'aide de sa MFT, ...)
Quelqu'un peut-il confirmer ou infirmer ?
Peut-être que les systèmes de fichiers Linux sont plus performant néanmoins.
Tu installes un Windows XP sur une partition de 15Go, tu fais les mises à jour et tu regardes la fragmentation, c'est lamentable... pour une machine qui n'a même pas encore servit en production.
# Passage d'ext4 en btrfs
Posté par Pinaraf . Évalué à 7.
Par contre je suis navré, j'ai lu ça sur lwn.net, mais je ne retrouve plus le lien.
[^] # Re: Passage d'ext4 en btrfs
Posté par Pinaraf . Évalué à 10.
# XFS roulaize des papas ours !
Posté par poil oq . Évalué à -9.
Et sinon il fait beau chez vous ?
Poil.
[^] # Re: XFS roulaize des papas ours !
Posté par Pierre Tramo (site web personnel) . Évalué à 4.
# Btrfs
Posté par vida18 . Évalué à 6.
[^] # Re: Btrfs
Posté par Vivien MOREAU . Évalué à 8.
[^] # Re: Btrfs
Posté par Nucleos . Évalué à 2.
[^] # Re: Btrfs
Posté par ribwund . Évalué à 2.
[^] # Re: Btrfs
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
# SSD
Posté par barmic . Évalué à 2.
Son développement seras plus rapide.
Par contre comment se débrouille Btrfs par rapport à la "concurrence" sur SSD ?
Je mettais arrêté à ça : http://linuxfr.org/2008/04/04/23938.html
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: SSD
Posté par 142857 . Évalué à 8.
[^] # Re: SSD
Posté par reno . Évalué à 3.
*: Ce qui explique d'ailleur pourquoi ils ont parfois des performances en écritures aléatoire pas terribles ces SSD quand ils commencent a être rempli..
[^] # Re: SSD
Posté par benoar . Évalué à 4.
[^] # Re: SSD
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Les SSD ont un autre énorme problème : la taille du bloc d'écriture. Il fait autour de 128Ko. Une écriture de 1 octets provoque une écriture de 128Ko. L'effet est d'avoir une vitesse d'écriture aléatoire de petit bloc très très lente. Certain SSD tombe à 4 écritures/s pour des blocs de 4ko, soit une latence de 250 ms ! On est loin des 0.1 ms promis !
Les 2 techniques pour limiter cette effet est la multiplication des "channels" de mémoire flash sur le contrôleur (4 chez certain, 10 pour celui d'intel) et l'ajout de mémoire cache SDRAM (j'ai déjà vu 32Mo).
Cette lenteur est très visible lors de la décompression d'un gros tar ou la copie de répertoire. La vitesse de décompression d'un noyau pourrait être un bon bench :)
"La première sécurité est la liberté"
[^] # Re: SSD
Posté par benoar . Évalué à 3.
Sinon, pour les problèmes de perf, je pense aussi que les algos de wear-leveling jouent beaucoup sur la lenteur : si c'est un algo merdique (vu comme le domaine doit être blindé de brevets, aussi ...), le fait d'écrire plein de petits blocs va vraiment le faire ramer. Ça plus les problèmes d'erase block, effectivement ça ne donne pas un joli résultat.
Enfin, en ce qui concerne la SDRAM, j'avais lu qu'elle ne servait pas de cache, mais de mémoire "opératoire" pour le chip qui fait le wear-leveling ; il y stocke diverses infos pour faire ses calculs, mais ce n'est pas un cache de données (à vérifier).
Enfin bon, comme d'hab, dans un domaine ou les constructeurs sont peu bavards, on ne peut pas faire mieux que de spéculer ...
[^] # Re: SSD
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Cela explique la chute de perf quand le SSD se remplit. D'après les white paper de samsung (?), ils agissent par bloc de 4Mo, dans lequel il font "tourner" les blocs. donc, si on écrit beaucoup dans un bloc de 4Mo, il tourne beaucoup, et il y a plus d'effacement/écriture.
"La première sécurité est la liberté"
[^] # Re: SSD
Posté par benoar . Évalué à 3.
[^] # Re: SSD
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: SSD
Posté par benoar . Évalué à 2.
[^] # Re: SSD
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Quel information de performance manquerait avec un "time tar xzf" en boucle jusqu'à remplissage de la partition ?
"La première sécurité est la liberté"
[^] # Re: SSD
Posté par benoar . Évalué à 2.
[^] # Re: SSD
Posté par windu.2b . Évalué à 10.
(vraie question, avec quelques morceaux de trolls dedans quand même)
[^] # Re: SSD
Posté par reno . Évalué à 3.
[^] # Re: SSD
Posté par benoar . Évalué à 3.
Oui, c'est clair que comme d'hab ce n'est pas MS qui va faire avancer les choses dans le sens des technologies futures ouvertes pour tout le monde (je les aurai bien vu sortir un truc rien qu'à eux .... tiens, d'ailleurs, voir les actus récentes sur l'ExFAT, le FS standard sur les nouvelles cartes SDXC, utilisable uniquement avec Vista SP1 ...). Et que tant qu'il ne se décident pas à bouger, personne ne le fera (enfin si, les libristes, mais tout le monde va encore leur rire au nez).
Par contre, le fait de réutiliser les connexions standards des périphériques magnétiques (ATA et SATA) est quand même un gros avantage, en ce qui concerne les standards matériels.
FTL et MTD ne sont pas vraiment des "modes". FTL c'est le nom de la puce (ou du mécanisme) qui traduit les commandes reçues, spécifiques au périphériques de type "bloc", en quelque chose qui va écrire sur les puces NAND.
Et MTD c'est le nom, sous linux, qu'ont les périphériques NAND qui sont accessibles par leur interface "native" : on ne peut pas choisir d'écrire un bloc au hasard, il faut effacer un erase block si quelque chose avait été écrit auparavant. Et le soft doit aussi gérer lui-même le wear-leveling : c'est un peu demandeur en ressources, mais ça permet de choisir _sa_ technique, et surtout d'évoluer au rythme su soft, et pas du hard.
Dommage que la Flash ne soit accessibles directement comme ça que sur les périphériques embarqués à mémoire inamovible.
PS: il n'existe pas aujourd'hui à ma connaissance de connexion matérielle standard pour relier de la Flash à un ordinateur. C'est con...
[^] # Re: SSD
Posté par reno . Évalué à 2.
Ce qui est curieux c'est que la Flash ne fournisse pas les deux modes, disque dur pour la compatibilité et 'natif' pour les performances, j'imagine que les quelques cents d'Euros en couts supplémentaire pour le contrôleur doivent être considéré comme inutile..
>>PS: il n'existe pas aujourd'hui à ma connaissance de connexion matérielle standard pour relier de la Flash à un ordinateur. C'est con...<<
Bin c'est surtout récent cette mode d'avoir des 'disques Flash' donc c'est normal de réutiliser l'existant (SATA / PATA)..
Mais on peut espérer qu'à terme les connexions soit directement sur du PCIExpress..
[^] # Re: SSD
Posté par benoar . Évalué à 2.
Heu ... le plus gros problème, c'est que le protocole ATA (et donc SATA) n'est simplement pas fait pour les périphériques non-"block". Ce n'est pas géré dans le protocole, donc ça ne peut pas être géré par le SSD.
Alors après, comme toujours, on pourrait inventer un petit "hack" pour faire passer des commandes MTD classiques par de l'ATA, mais à ma connaissance ça n'a jamais été fait.
Mais on peut espérer qu'à terme les connexions soit directement sur du PCIExpress..
Il faut voir ce que tu veux dire par "PCIExpress", parce que mettre une NAND connectée à du PCIe, ça veut mettre un contrôleur qui utilisera un certain protocole de communication avec l'hôte. Et pour que ce soit pas le bordel, il faudrait que ce protocole soit standarisé. Vu comme est partie l'industrie (i.e. pas dans cette voie, à part quelques exceptions), je ne pense pas que ça arrivera (tous ceux qui voudraient s'y lancer aujourd'hui auront quelques bons wagons de retard sur la concurrence si leur truc ne marche pas "out of the box").
[^] # Re: SSD
Posté par reno . Évalué à 2.
Oui, c'est a ça que je pensais comme type de bidouille, c'est quand même un peu rallant de faire d'avoir des perf en écriture aléatoire sous-optimale a cause de limitations dans le micro-contrôleur qui gere le SSD alors que le CPU pourrait aider..
Pour ce qui est du SSD sur PCIExpress, il y en a qui bosse dessus, après est-ce que cela va prendre ou pas, pas la moindre idée..
http://www.theregister.co.uk/2008/10/14/fusionio_pcie_connec(...)
[^] # Re: SSD
Posté par Antoine . Évalué à 7.
Linus Torvalds n'est pas d'accord :
« The only sane flash model is one where the hardware itself
does the block remapping.
And no, this is not about "most filesystems" or about any
majority voting. It's a simple technical fact.
The simple fact is that exposing the internal flash
model to any external software is simply insane. [...] »
http://realworldtech.com/forums/index.cfm?action=detail&(...)
[^] # Re: SSD
Posté par benoar . Évalué à 4.
D'un coté, il n'a pas complètement tort, ça permet d'abstraire les différences du hard, et de mieux optimiser le wear-leveling en fonction du matos particulier, même si je trouve sa comparaison avec la DRAM un peu foireuse, vu que ce que fait le contrôleur de la DRAM est très basique par rapport à ce que doit faire le contrôleur de la NAND.
Mais bon, dire qu'on devrait plutôt ne pas acheter le mauvais matos, c'est facile à dire mais pas à faire : en gros, on doit éviter _toutes_ les cartes SD/CF/... qui ont toutes du wear-leveling pourri, et quasi tous les SSD saufs peut-être ceux d'Intel. Ça limite quand même beaucoup le choix ...
Sinon, moi la chose qui me plaisait dans le "raw access" à la flash, c'est le coté on est libre de wear-leveler comme on veut.
# Reiserfs
Posté par Pierre Jarillon (site web personnel) . Évalué à 3.
On retrouve par exemple dans Btrfs une gestion performante des petits fichiers et d'autres caractéristiques de Reiserfs. Actuellement, reiserfs est mon système de fichier préféré mais au vu des caractéristiques de btrfs, il se pourrait bien que je change ma préférence.
Il semble que Reiser4 n'évolue plus vraiment depuis l'incarcération de Hans Reiser. C'est dommage car il y a dans Reiser4 des fonctions vraiment novatrices. Voir http://web.archive.org/web/20071023172417/http://www.namesys(...) . Pourtant http://lkml.org/lkml/2008/4/18/390 annonce en avril 2008 sa prise en compte par le kernel.
La page listant les FS de Linux ne semble pas très à jour : http://www.linux.org/lessons/advanced/x1254.html
[^] # Re: Reiserfs
Posté par Kyle_the_hacker . Évalué à -1.
[^] # Re: Reiserfs
Posté par Pierre Jarillon (site web personnel) . Évalué à 1.
Il avait passé tout son temps avec David Axmark à ses côtés sur la photo. Ils avaient beaucoup discuté des analogies entre la gestion des transactions des bases de données et la journalisation des FS.
Je crois qu'il en est ressorti quelques progrès de part et d'autre.
Reconnaissez-vous les autres personnes de la photo ?
[^] # Re: Reiserfs
Posté par Steven Le Roux . Évalué à -4.
[^] # Re: Reiserfs
Posté par téthis . Évalué à 8.
The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein
[^] # Re: Reiserfs
Posté par Steven Le Roux . Évalué à -1.
[^] # Re: Reiserfs
Posté par herodiade . Évalué à 10.
Oui, et de loin franchement.
Ses fonctionnalités sont déjà largement en avance par rapport à celles de reiserfs (et reprennent comme tu le signale les bonnes propriétés de celui-ci).
Le plus important (à mes yeux, concernant un système de fichier, et en comparaison avec reiserfs) est qu'il promet d'être très activement maintenu, suscitant l'intérêt vif et la participation de développeurs critiques chez IBM, Red Hat, SUSE, Oracle, Intel. Cette diversité est prometteuse, car elle signifie que bientôt chacune de ces sociétés sera capable de gérer les bugs rencontrés par ses clients, donc en mesure de proposer et supporter officiellement ce système de fichiers, de l'affiner pour ses workloads spécifiques, etc. Par contraste, reiserfs est désormais en mode "maintenance faible" chez SUSE et Mandriva, son développeur principal ne participe plus, et il n'est tout simplement pas supporté par Red Hat (autrement dit : peu de chances d'améliorations fonctionelles, désormais, à la différence de ext4, XFS et btrfs).
Une fonctionnalité bluffante pas décrite dans la dépêche, et pas faisable avec les outils actuels (LVM) : btrfs permet de faire des snapshots d'un répertoire quelconque du système de fichier (par ex. juste le /etc). D'autre part, il n'est pas nécessaire de réserver de l'espace disque dès le départ pour pouvoir faire ses snapshots (comme avec LVM). Ce sont de petits détails, mais il y en a beaucoup comme ça, et ils chacun peu, je pense, changer la vie des sysadmins :).
Pour répondre à la question de Michel plus haut :
> Par contre comment se débrouille Btrfs par rapport à la "concurrence" sur SSD ?
Pour le moment btrfs ne fait pas grand chose de spécifique pour les SSD. En pratique : la routine de recherche permettant de trouver de l'espace libre et utilisable parmi les extents alloués dispose d'un raccourcis/court-circuit dans le cas du SSD.
Mais il est prévu d'essayer de tirer le meilleur partis, de façon spécifique, des SSD, c'est d'ailleurs pour ça qu'une option de montage spécifique "ssd" est déjà intégrée.
XFS (depuis peu, et de façon encore expérimentale) et btrfs intègrent des fonctionnalités de gestion des périphériques multiples (normalement dévolues aux couches MD et LVM du noyau) précisément pour se permettre ce genre d'optimisations : en connaissant précisément la couche physique (le matériel sous-jacent), ils pourront décider au mieux de l'agencement des données. Par exemple, dans un aggrégat de disques durs et de SSD : placer les métadonnées (nécessitant beaucoup d'accès aléatoires) sur le SSD et les données dont l'accès est plus séquentiel sur disque dur, ou encore (et parce que, pour des raisons de fiabilité, btrfs permet de dupliquer les métadonnées critiques) savoir comment répartir les diverses copies sur des disques effectivement physiquement différents est difficile lorsque cette information est masquée par l'agrégation LVM ou MD.
Et aussi : btrfs (comme ZFS en fait) peut (si monté en conséquence) s'assurer de l'intégrité des données à l'aide de checksums (pour le moment, uniquement des crc32). S'il a un accès direct aux disques physiques (direct = pas déjà agrégé / masqué par une couche raid sous-jacente), il peux décider de chercher une copie en bon état du bloc concerné, puis la dupliquer de nouveau sur le disque où la copie était mauvaise (mais dans un autre bloc), voir prendre des décisions pertinentes au sujet des blocs contigus ou du disque lui-même. Un gestionnaire RAID classique, lui, ne pouvant pas accéder aux informations du fs, se contentera de mettre le disque entier offline dès qu'il détectera le problème. C'est une problématique importante, justement, pour les SSD (dont certains blocs peuvent "vieillir" sans que l'ensemble du périphérique soit à jetter), et en fait, avec les gros disques modernes (le risque d'une panne globale du disque est aussi grand qu'auparavant, mais le risque d'avoir un ou deux blocs défectueux augmente au fur et à mesure que les disques grossissent en capacité).
Ou encore : sur un système RAID classique (logiciel avec mdadm ou lvm, ou matériel), la couche RAID permet d'avoir une seule taille de stripe, définie à la construction de l'agrégat. Ce choix n'est pas optimal pour tout les cas, même lorsque le système de fichier est proprement aligné sur les stripes (par ex. avec l'option "stride" d'ext3/ext4) : les lectures/écritures séquentielles de gros fichiers bénéficient de larges stripes, tandis que les petites écritures (métadonnées, par ex.) bénéficient de petites stripes (sans quoi, les écritures successives seront mal réparties sur les divers disques physiques de l'array). Or le système de fichier dispose de ses informations (taille probable des lectures/écritures) ; il est donc en mesure de prendre de très bonnes décisions en allouant des stripes de taille dynamique selon ses besoins spécifiques.
Je signale au passage que sur ce point (la fameuse "rampant layering violation") cette dépêche est fausse.
Je suppose qu'elle a été écrite à partir de l'article de patrick_g sur Wikipédia, qui se base sur des informations juste mais datées. En pratique, Chris Mason avait l'intention d'essayer de faire un fs qui communique et délègue aux couches pertinentes (d'où le texte dans l'article de WP), mais s'est aperçu ensuite qu'il devait gérer l'essentiel dans le système de fichiers lui-même pour pouvoir exploiter de façon optimale les périphériques multiples (cf. plus haut), les snapshots, etc.
En somme, l'intention de départ était bien, effectivement, de ne pas "violer" les divers "block layers" du noyau, mais ce qui s'est réellement passé c'est que la mentalité des développeurs Linux a globalement évolué sur ce point, et que ce type de "violations" est désormais considéré comme légitime (dans une certaine mesure). Le paradigme a simplement changé, les développeurs Linux ne sont pas obtus.
Voyez cette paire de réponse de Christophe Hellwig (développeur de XFS) et Chris Mason (développeur de btrfs) à Andrew Morton qui s'interrogeait récemment sur cette question de "layering violation" :
http://thread.gmane.org/gmane.comp.file-systems.btrfs/1601/f(...)
http://article.gmane.org/gmane.comp.file-systems.btrfs/1764
[^] # Re: Reiserfs
Posté par FantastIX . Évalué à 2.
[^] # Re: Reiserfs
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
> système de fichier
Cette fonctionalité est géniale car elle va permette de faire des sauvegardes à cout CPU quasi nul. Il va être très facile de programmer des retours arrières pour tout un tas d'opération (upgrade de système par exemple). Cette fonctionalité va de paire avec le snashot de snapshot. Les possibilités sont énormes.
> Je suppose qu'elle a été écrite à partir de l'article de patrick_g sur
> Wikipédia
Je ne sais pas si Patrick a écrit la version anglaise sur Wikipedia. Je suis partis sur cette version la car je savais que pas mal de personne sauterais sur la version Française de wikpedia. Ainsi le débat n'est en que plus animé, la version anglaise étant assez différente de la version française.
Au niveau de la séparation avec la couche LVM et le fait que cette séparation ne soit pas effective, je trouve cela dommage. J'aurais préféré que le système LVM et le device-mapper soient étendus afin de pouvoir répondre aux questions existentielles des systèmes de fichier.
Sinon, je n'y connais rien en système de fichier, j'essaye juste d'être un utilisateur avertis ;-)
Sinon, il y a une "extension" a BrtFS qui me semble aussi intéressante : CRFS (Coherent Remote File System), Il s'agit en fait d'une couche réseau pour accéder au système de fichier à distance. A suivre... car je ne sais pas ce que cela apporte par rapport a du NFSv4 ou du parrallèle NFS. En tout cas, il est bien préciser que CRFS se base sur les fonctionalités de BtrFS.
[^] # Re: Reiserfs
Posté par patrick_g (site web personnel) . Évalué à 2.
Non pas du tout. J'ai simplement posté une partie de ma news LinuxFR dans l'article français : http://fr.wikipedia.org/wiki/Discuter:Btrfs
[^] # Re: Reiserfs
Posté par windu.2b . Évalué à 4.
On pourrait peut-être même imaginer des VCS reposant sur les snapchsots, non ?
Bon, je sais que cela induirait forcément une dépendance forte entre le soft et le FS, ce qui n'est sans doute pas recommandé... Mais l'idée ne tiendrait-elle pas la route ?
(c'est une vraie question).
[^] # Re: Reiserfs
Posté par vieuxshell (site web personnel) . Évalué à 1.
Un des principes de bases d'un VCS est de pouvoir "tourner" sur plusieurs platformes donc ne relier le soft qu'a un FS sur un OS ce n'est pas très interssant (même si on peut imaginer une couche d'abstraction pour ZFS).
Sur un système centralisé (comme subversion) ca peut être utilisé sur le serveur mais il peut y avoir un risque en terme de sauvegarde. Il faut être certain que l'on pourra toujours acceder aux données dans 10,15 ou 20 ans. Je pense que ce risque est plus fort si on dépend d'un FS que d'un format de fichier indépendant.
La ou c'est plus interessant, comme indiqué plus haut, c'est la possibilité pour tout un tas de soft de proposer, facilement ,des fonctionnalités transactionnelles sans dépendre d'un DB.
[^] # Re: Reiserfs
Posté par Kerro . Évalué à 2.
Il reste un truc pas très joli: "Si des données sont écrites sur un bloc mémoire alors ce dernier sera copié à un autre endroit du système de fichiers et les nouvelles données seront enregistrées sur la copie au lieu de l'être sur l'original."
Je n'ai pas trouvé comment remanier la phrase.
[^] # Re: Reiserfs
Posté par Snarky . Évalué à 7.
Rhoo, il abuse, franchement... Abandonner son FS comme ça...
[^] # Re: Reiserfs
Posté par ribwund . Évalué à 5.
# Ext4 ou Brtfs ?
Posté par jiyuu . Évalué à 4.
Parce qu'avec toutes ces fonctionnalités Brtfs à l'air plus intéressant que Ext4.
Et aussi, est-ce que Ext4 n'est-il pas voué à être un fs de remplacement que peu de personne auront utilisé ?
[^] # Re: Ext4 ou Brtfs ?
Posté par Vivien MOREAU . Évalué à 8.
Btrfs est encore très loin de l'être !
Il faut voir Btrfs comme le futur successeur de Ext4, je ne lis pas ça dans une boule de cristal, c'est Theodore T'so, le développeur principal de Ext4 qui le dit :-) !
[^] # Re: Ext4 ou Brtfs ?
Posté par vladislav askiparek . Évalué à 4.
Ext4 est-il vraiment recommandé en production?
En fait, on en parle peu. Peut-être qu'il est stable.
[^] # Re: Ext4 ou Brtfs ?
Posté par Pinaraf . Évalué à 3.
[^] # Re: Ext4 ou Brtfs ?
Posté par claudex . Évalué à 2.
« 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: Ext4 ou Brtfs ?
Posté par auve . Évalué à 7.
Ted Tso, développeur principal d'Ext4, et d'autres spécialistes des systèmes de fichiers se sont mis d'accord lors du dernier workshop dédié à ce sujet pour adouber Btrfs « NGFS » : Next-Generation File System, c'est à dire le principal futur système de fichier moderne pour Linux.
Ted Tso signale également qu'il est pleinement pour l'intégration de Btrfs dans le noyau, donc a priori il ne me semble pas du tout y avoir de rivalité entre lui et son auteur, Chris Mason.
Source : http://thread.gmane.org/gmane.linux.file-systems/26246/focus(...)
[^] # Re: Ext4 ou Brtfs ?
Posté par IsNotGood . Évalué à 2.
Comme le disent d'autres commentaires, ça sera Ext4 ET Btrfs. Comme ça a été Ext2 ET Ext3, comme ça sera et c'est maintenant Ext3 ET Ext4.
De nombreux mois, et très probablement des années, vont passer avant que Btrfs soit au point. Ext4 est déjà au point (ou plus très loins). Btrfs est le remplaçant à venir de Ext4. Ext4 roxe, donc Btrfs sortira (en 1.0) lorsqu'il roxera, qu'il n'y aura pas de régression par rapport à Ext4, qu'il sera aussi fiable et apportera son petit plus par rapport à Ext4. BtrFS a quasiment la garantit d'y arriver car nombre de développeurs Ext vont bosser sur BtrFS. Donc Ext4 va stagner et BtrFS progresser.
Je vais en froisser quelqu'uns, mais Ext* a été (et est toujours) LE système de fichier de Linux. BtrFS sera LE système de fichier de Linux.
En passant, Ext4 est dans F10 (faut ajouter "ext4" lors du boot de l'installation). Je l'utilise, rien à dire sinon que ça marche. Il sera peut-être par défaut pour F11. Il sera très probablement par défaut pour RHEL 6. Novell a abondonné Reiser(FS|4) pour Ext*. Ext4 sera par défaut dans la distribution entreprise de Novell. Ext4 répond aux besoins actuels. Ça donne du temps à BtrFS. Pas pour flémarder, mais pour innover.
[^] # Re: Ext4 ou Brtfs ?
Posté par IsNotGood . Évalué à 1.
Ou une autre façon de le dire : Ext4 n'est pas un concurrent de BtrFS, c'est une chance pour BtrFS.
[^] # Re: Ext4 ou Brtfs ?
Posté par foulmetal canette (site web personnel) . Évalué à 3.
En attendant ext4 a tout de même son intérêt : http://www.phoronix.com/scan.php?page=article&item=ext4_(...)
# Gestion de la défragmentation lors de l'utilisation en tâche de fond
Posté par lrbabe . Évalué à 2.
Quelqu'un pourrait éclairer ma lanterne ?
[^] # Re: Gestion de la défragmentation lors de l'utilisation en tâche de fo
Posté par alexissoft . Évalué à 7.
[^] # Re: Gestion de la défragmentation lors de l'utilisation en tâche de fo
Posté par IsNotGood . Évalué à 2.
C'est le cas. D'ailleurs on trouve rarement des défragmenteur sous Linux.
Ici c'est de l'optimisation pour des serveurs très stressés ou +5% de performance peut être important. C'est n'est pas pour une optimisation de "desktop".
Ext4 a aussi la défragmentation à chaud.
[^] # Re: Gestion de la défragmentation lors de l'utilisation en tâche de fo
Posté par bertrand . Évalué à 10.
Il faut préciser qu'on partait de loin : les système de fichier MS de l'époque utilisaient une liste chaînée des blocs libres pour trouver le prochain bloc à allouer. (il prenait le premier bloc de la liste). En somme un choix aléatoire du bloc suivant du fichier !
Ext2 utilise un algorithme qui prend en compte la proximité des blocs. Ext3 et Ext4 améliorent l'algorithme d'Ext2.
Néanmoins si ton système de fichier est bien rempli, le bloc libre le plus près peut être très éloigné !
C'est dans ces cas là qu'Extn fragmentent.
[^] # Re: Gestion de la défragmentation lors de l'utilisation en tâche de fo
Posté par Fabimaru (site web personnel) . Évalué à 2.
[^] # Re: Gestion de la défragmentation lors de l'utilisation en tâche de fo
Posté par foulmetal canette (site web personnel) . Évalué à 2.
# fix typo
Posté par Mathieu Schroeter (site web personnel, Mastodon) . Évalué à 2.
s/Brtfs/Btrfs/g
# Pendant ce temps là, en parlant de système de fichiers...
Posté par cosmocat . Évalué à 10.
http://www.zdnet.fr/actualites/informatique/0,39040745,39386(...)
Et encore une fois, il utilise un système de fichier d'avenir (exFat), ouvert au possible, sans royalties ni brevet d'une petite PME de seattle et actuellement lisible qu'avec Vista Sp1 (exit actuellement tous les autres).
http://fr.wikipedia.org/wiki/ExFAT
Encore un choix censé!!
[^] # Re: Pendant ce temps là, en parlant de système de fichiers...
Posté par Pinaraf . Évalué à 7.
Ça c'est de la killer feature, tous les boutonneux de linuxiens, bsdistes et autres maceux vont pleurer leur race devant ça...
# LVM Obsolète ?
Posté par Ririsoft . Évalué à 2.
Je me pose une question et la news (de qualité :-) ) n'est pas très claire sur le sujet :
Est-ce que Btrfs va rendre obsolète l'utilisation de softs comme LVM comme c'est le cas avec ZFS ?
En particulier est-ce que l'on pourra redimensionner (agrandir ET rétrécir) une partition Btrfs sans soucis et se passer de LVM pour ce genre de tâche !
Merci de vos éclaircissement !
[^] # Re: LVM Obsolète ?
Posté par Psychofox (Mastodon) . Évalué à 4.
[^] # Re: LVM Obsolète ?
Posté par thomas . Évalué à 2.
Quand à la réduction d'un zpool (enlever un device du zpool), ce n'est effectivement pas possible, pour le moment....
[^] # Re: LVM Obsolète ?
Posté par herodiade . Évalué à 5.
Suppose your Mountpoint is /mnt:
add 2GB to the FS
btrfsctl -r +2g /mnt
shrink the FS by 4GB
btrfsctl -r -4g /mnt
Explicitly set the FS size
btrfsctl -r 20g /mnt
Use 'max' to grow the FS to the limit of the device
btrfsctl -r max /mnt
Citation de http://btrfs.wiki.kernel.org/index.php/Btrfsctl
[^] # Re: LVM Obsolète ?
Posté par zebra3 . Évalué à 3.
Ce que chicha demande, c'est si Btrfs peut remplacer LVM, et donc offrir toutes les fonctionnalités de celui-ci, comme l'aggrégation de disques (avec possibilité de stripping) et le découpage en volumes logiques.
Pour l'instant ce n'est pas le cas, mais sait-on jamais, ça sera peut-être dans la version 1.0, pourquoi pas ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: LVM Obsolète ?
Posté par herodiade . Évalué à 1.
Pour ce qui est de l'agrégation de disques et du stripping, voyez (pas tout à fait à jour d'ailleurs) :
http://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Mult(...)
ça me semble déjà pas mal, pour un début :)
[^] # Re: LVM Obsolète ?
Posté par zebra3 . Évalué à 2.
Enfin, ce lien est très intéressant, ça veut dire que Btrfs sera plutôt équivalent à ZFS qu'Ext. Personnellement, je trouve un peu dommage d'outrepasser le device mapper (qui devait être me semble-t-il l'unique point d'accès au stockage dans le noyau) et d'accéder directement aux disques pour toutes ses manipulations internes.
Certes, ça doit énormément simplifier l'administration (par exemple, pas de casse-tête lors de la réduction d'un fs, où une opération par couche est nécessaire, tout en tenant compte des écarts...), mais j'aime bien l'idée actuelle des couches séparées, qui permet de faire tout et n'importe quoi (chaque élément pouvant contenir n'importe quel élément).
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: LVM Obsolète ?
Posté par briaeros007 . Évalué à 4.
Donc tu peux faire tout et n'importe quoi, mais ca te rajoutera de l'administration.
avec zfs (sous linux) c'est la meme chose, si tu veux créer un device sur un loopback par exemple, tu peux sans problème. Par contre il pourrait pas utiliser (de façon optimale tout du moins) ses algorithmes de réplication et de choix des blocs itou.
[^] # Re: LVM Obsolète ?
Posté par Ririsoft . Évalué à 1.
herodiade : c'est exactement ce que je voulais savoir. Je n'utilise LVM que pour pouvoir agrandir et réduire des partitions ext3 sans souci et jouer avec mes partitions sur un seul disque seulement (j'ai deux disques mais un groupe par disque).
Guillaume : tu réduis souvent des ext3 en dehors d'un LVM ? ça se passe bien ? si oui alors dans mon cas LVM ne sert à rien ?
[^] # Re: LVM Obsolète ?
Posté par zebra3 . Évalué à 3.
Non, j'utilise LVM+ext3 pour les mêmes raisons que toi, à savoir réduire des fs et réallouer l'espace libre à d'autres fs, ce qui n'est pas possible sans un outil de volumes logiques (ou alors je ne sais pas comment).
J'ai déjà pu expérimenter la réduction de fs ext3 sur des partitions classiques : ça se passe bien, mais j'ai toujours une certaine appréhension. En effet, une fois que tu as réduit le fs, la méthode consiste ensuite à supprimer la partition puis la recréer avec une taille plus petite. Tu comprendras que je ne suis pas fan du fait de supprimer une partition... Et en plus, pour utiliser l'espace gagné, tu dois créer une nouvelle partition.
Finalement, la solution LVM reste la plus souple et a fait ses preuves, autant y rester pour l'instant.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: LVM Obsolète ?
Posté par Ririsoft . Évalué à 2.
Nous avons les mêmes besoins et nous utilisons LVM de la même façon pour y répondre :-)
Maintenant c'est toujours pas super clair pour moi si oui ou non je vais pouvoir me passer de LVM pour gérer mon disque. J'ai peur que non :
Cas LVM :
Si j'ai bien compris et en schématisant : LVM permet de gérer un pool de blocs et d'allouer tel ou tel quantité de blocs a tel ou tel volume logique lui-même associé à une partition. Un des intérêts c'est que l'on peut réorganiser tout ça sans perte de données.
Cas Btrfs :
Dans le cas ou j'aurais un disque avec 3 partitions Btrfs sans LVM.
Est-ce que je pourrais réduire 2 d'entre elles et en créer facilement une 4ième avec l'espace libéré ? Est-ce qu'on pourra créer une partition avec des blocs libérés un peu n'importe ou sur le disque ? Je doute fort non ?
Votre avis m'intéresse !
Merci beaucoup :-)
[^] # Re: LVM Obsolète ?
Posté par briaeros007 . Évalué à 3.
Tu attribue des disques à ton Zfs, et _dans_ ton fs, tu attribue ce que tu veux (quota ET réservation d'espace!) pour les fs/répertoire que tu as crée.
La facilité d'administration des fs (qui s'utilisent comme des répertoires) permet ça.
(bon par contre ça oblige l'utilisation de zfs, donc peut pas utiliser cette place pour quelque chose qui comprend pas zfs).
J'ai vu des gens s'extasier devant des portages iscsi et une solution propriétaire très cher qui permettait de "réserver" de l'espace disque et donc d'exporter des disques virtuels (par dessus un SAN) par iscsi qui pouvaient être modifié dynamiquement en taille.
Et quand je leur ais dit que je pouvais le faire pour juste le cout du hardware avec un solaris et zfs ils m'ont pas cru XD.
[^] # Re: LVM Obsolète ?
Posté par Sylvain AVRIL (site web personnel) . Évalué à 2.
Vraiment très intéressant cet approche que je reprochais à ZFS. J'applaudis des 2 mains.
[^] # Re: LVM Obsolète ?
Posté par zebra3 . Évalué à 5.
Does the Btrfs multi-device support make it a "rampant layering violation"?
Yes and no. Device management is a complex subject, and there are many different opinions about the best way to do it. Internally, the Btrfs code separates out components that deal with device management and maintains its own layers for them. The vast majority of filesystem metadata has no idea there are multiple devices involved.
Many advanced features such as checking alternate mirrors for good copies of a corrupted block are meant to be used with RAID implementations below the FS.
Les devs sont donc conscients de l'importance de cette hierarchie des couches, mais certaines optimisations nécessitent des fonctions plus bas niveau que ne le permet celle-ci. Donc pour rester cohérent, Btrfs est développé en séparant le FS pur de la gestion matérielle, ce qui permet à l'utilisateur soit de respecter cette convention, soit de l'ignorer s'il veut profiter d'une implémentation optimale.
Autrement dit, cette approche me paraît très ouverte et pragmatique, bien plus que ton commentaire ne l'affirme. Je crois qu'on peut s'attendre à un résultat très impressionnant.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
# Et Tux3 ?
Posté par téthis . Évalué à 6.
Je me suis intéressé à ce FS à la fin de l'année dernière, par curiosité et parce que le nom est amusant. Au début de l'année j'ai enfin pu compiler un module kernel à partir des sources récupérées sur le dépôt mercurial et copier quelques fichiers sur une partition tux3 (c'était le seul objectif fixé). La doc que j'ai trouvée était très technique et volait bien au dessus des mes simples connaissances en système de fichiers.
Pensez-vous que tux3 soit un système de fichiers qui a des chances de percer et de finir un jour à côté de btrfs, pas forcément au même niveau ? Ou alors quelques petites informations accessibles sur tux3 afin de comprendre un peu plus l'engin et, par exemple, pouvoir le comparer à btrfs si il y a moyen de faire.
Pour l'instant ext3 me convient parfaitement, c'est seulement au titre de ma curiosité maladive que je me permets de demander. :)
The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein
# Snapshot ...
Posté par Pol' uX (site web personnel) . Évalué à 3.
À mon avis ce serait vraiment une fonctionnalité intéressante de pouvoir faire, dans mon gestionnaire de fichier, click droit -> créer un point de restauration ; ou encore de choisir la version actuelle de travail en un click.
Certes ça n'aurait pas la vocation à concurrencer Git (notamment du fait de la duplication totale du fichier à la création du snapshot), mais pour un utilisateur "lambda" (comme moi) ce serait une fonctionnalité intéressante.
(en fait peut être est-ce déjà dans la roadmap de btrfs, je n'ai pas vérifié l'info...)
Adhérer à l'April, ça vous tente ?
[^] # Re: Snapshot ...
Posté par ribwund . Évalué à 4.
Git fait une duplication totale des fichiers. Tant qu'il n'y a pas eu de repack, chaque version de chaque fichier à sa propre copie sur le disque.
[^] # Re: Snapshot ...
Posté par Pol' uX (site web personnel) . Évalué à 1.
Adhérer à l'April, ça vous tente ?
[^] # Re: Snapshot ...
Posté par herodiade . Évalué à 3.
Cela étant, les snapshots (de tout le root fs) sont d'ors et déjà peu couteux (COW oblige).
[1] C'est indiqué, par exemple, dans la timeline de btrfs, ici: http://oss.oracle.com/projects/btrfs/dist/documentation/todo(...)
Le site oss.oracle.com est entièrement down pour le moment, désolé, voici une version en cache :
http://209.85.129.132/search?q=cache:j0rkDJXeAQMJ:oss.oracle(...)
Ou si tu préfère, voici un article qui cite cette timeline (dernier paragraphe) : http://lwn.net/Articles/265257/
[2] Ce qu'en dit Chris Mason directement (là aussi, l'archive de la m-l est sur oss.oracle.com ...) :
http://209.85.129.132/search?q=cache:GBzfRbsdgtAJ:oss.oracle(...)
[^] # Re: Snapshot ...
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
> en cache :
Pas de pot, je fais une dépêche la dessus et leur site est HS depuis déjà un bout de temps. Idem tout à l'heure, je n'ai pas pu mettre la référence de la partie réseau associé BtrFS.
A mon avis, on est trop nombreux à vouloir y aller ! DLFP a trop de succés !
[^] # Re: Snapshot ...
Posté par windu.2b . Évalué à 3.
Non justement, le fichier n'est pas entièrement recopié lors de la création du snapshot, grâce au "copy-on-write", qui crée de nouveaux blocs dès qu'un bloc snapshoté est modifié (donc tous les blocs identiques entre le snapshot et la version courante, sont en fait communs).
[^] # Re: Snapshot ...
Posté par Pol' uX (site web personnel) . Évalué à 1.
Adhérer à l'April, ça vous tente ?
[^] # Re: Snapshot ...
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
C'est exactement ce que fait LVM lors d'un snapshot.
# Fin des ajouts dans le 2.6.29
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
http://lwn.net/Articles/314471/
Au bilan, les trois grands apport de cette version seront
* squashfs : un système de fichier compressé en lecture seule
* Btrfs (en mode développement, pas pour l'utilisateur lambda)
* Les "modes settings" pour les cartes graphiques Intel (chose que faisait avant X-Window et qui bascule petit à petit dans le noyau).
[^] # Re: Fin des ajouts dans le 2.6.29
Posté par patrick_g (site web personnel) . Évalué à 8.
[^] # Re: Fin des ajouts dans le 2.6.29
Posté par Sytoka Modon (site web personnel) . Évalué à 6.
# Granularité du COW ?
Posté par PhE . Évalué à 3.
Dit autrement, lorsqu'une portion d'un fichier est modifiée par COW, est-ce l'ensemble du fichier qui est dupliqué ou seulement la partie modifiée ?
Je me pose la question de le cadre de "gros" fichiers et plus particulièrement pour des images disques de machines virtuelles où les snapshot BTRFS pourraient se substituer aux snapshot de VM.
[^] # Re: Granularité du COW ?
Posté par Arnaud . Évalué à 4.
Il me semble que c'est aussi le cas pour btrfs, mais je n'ai pas encore bien digéré l'explication du design, à lire pour les mordus de FS: http://btrfs.wiki.kernel.org/index.php/Btrfs_design
[^] # Re: Granularité du COW ?
Posté par Paerro Trime . Évalué à 3.
Par nature le copy-on-write defait toute stratégie d'effacement sécurisé puisque les blocs ne sont pas écrasés mais réécrits à côté. L'attitude adoptée par ZFS comme Btrfs pour l'instant, c'est "on l'a mis dans la roadmap" ; Chris Mason a déjà dit que ça serait pas dans la version 1.0 de Btrfs et que la solution qui avait sa faveur était de crypter les blocs, ainsi l'effacement sécurisé revient à jeter la clef. Cette solution pose quand même des petits problèmes, en particulier si on sait pas au départ quels fichiers devront faire l'objet d'un effacement sécurisé, il faut tout crypter - en plus pour que ça soit crédible il faut crypter sérieusement, et ça ça a un coût.
[^] # Re: Granularité du COW ?
Posté par François B. . Évalué à 1.
StackOverflowError at Brain (unknown location)
(oui, je sais, mon cerveau a une pile *très* limitée...)
[^] # Re: Granularité du COW ?
Posté par Sytoka Modon (site web personnel) . Évalué à 0.
> puisque les blocs ne sont pas écrasés mais réécrits à côté.
Je ne vois pas ou est le problème...
Pour vraiment effacer les données, il faut ré-écrire dessus un certain nombre de fois et non une seule fois.
Rien n'empêche d'écrire le fihcier n+1 sur l'ancien fichier n.
Mieux encore, rien n'empêche d'avoir une option de montage, du style 'secure-delete' qui écrirait dans un journal tous les block qui ne servent plus et qu'un processus parallèle de BtrFS s'occuperait en tâche de fond d'effacer entre 4 et 7 fois avec des données aléatoires.
Bref, je ne vois pas ou est la sécurité de ré-écrire au même endroit.
[^] # Re: Granularité du COW ?
Posté par benoar . Évalué à 2.
[^] # Re: Granularité du COW ?
Posté par briaeros007 . Évalué à 2.
[^] # Re: Granularité du COW ?
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
[^] # Re: Granularité du COW ?
Posté par Paerro Trime . Évalué à 4.
Le problème est que ça marche bien avec un système de fichier du type ext3 par exemple par que si tu lui dit écrase le contenu du bloc N avec ce pattern, il va effectivement écrire par dessus le bloc N qui sera ensuite illisible, l'implémentation du système de fichier n'a pas à le savoir c'est en dehors de son domaine.
Quand on utilise du COW, l'implémentation du système de fichier va écrire un nouveau bloc autre part sur le disque (ou plusieurs éventuellement dans un scénario RAID-Z et co) et marquer simplement l'ancien comme libre à la fin. Donc le secure delete a besoin d'un support au niveau du fs pour fonctionner (ce qui est un problème différent de la manière dont il est exécuté) et actuellement ce support n'existe à ma connaissance pas dans l'implémentation de ZFS, ni dans celle dans Btrfs, il est simplement "envisagé" (comme dans "on y réfléchit"). Pour l'instant le secure delete dans Btrfs ou ZFS, tintin, et il vaut donc mieux le savoir.
[^] # Re: Granularité du COW ?
Posté par briaeros007 . Évalué à 1.
# Défragmentation
Posté par floriang . Évalué à 1.
En gros, la fragmentation est comme sous Windows (avec FAT* et NTFS), puisqu'il y a besoin de trouver un moment pour défragmenter ??
Quelles sont les différences entre la fragmentation des EXT* et de BTRFS ?
[^] # Re: Défragmentation
Posté par claudex . Évalué à 2.
« 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: Défragmentation
Posté par phoenix (site web personnel) . Évalué à 1.
Quelqu'un peut-il confirmer ou infirmer ?
Peut-être que les systèmes de fichiers Linux sont plus performant néanmoins.
[^] # Re: Défragmentation
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Tu installes un Windows XP sur une partition de 15Go, tu fais les mises à jour et tu regardes la fragmentation, c'est lamentable... pour une machine qui n'a même pas encore servit en production.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.