En fait LVM à mon avis ne correspond pas au besoin. un fs sur du "matériel logique" qui peut se répartir sur plusieurs disques réels.
LVM c'est pour la [i]souplesse[/i], tu répartis tes fs/swaps/etc. (ya autre chose?) comme tu veux sur tes disques physiques, et tu peux même tout changer quand ça te plaît.
chunkfs c'est pour la [i]robustesse[/i], le fs apparent est découpé en entités autonomes. En casser une ne casse pas tout et en réparer une n'exige pas de démonter tout le fs.
Pour enfoncer le clou : on peut bien sûr utiliser les deux en même temps, créer des chunfs (constitué de plusieurs ext3/4/reiser/machinfs un peu modifiés) sur une partition crée en LVM.
Gardons en tête que chunkfs est un [i]proposition[/i] même pas implémentée (et peut ête ne le sera-t-elle jamais vraiment) qui répond à UN problème (qui d'ailleurs est bien décrit dans les liens, il faut les lire) : le fait que les tailles des disques augmente [i]beaucoup[/i] plus vite que 1. les temps d'accès (et aussi les vitesses de transfert mais ici c'est pas important) et 2. la vitesse des algos de fsck (qu'il ne prévoient pas de pouvoir augmenter d'un facteur 100), avec pour conséquence des temps de fsck de plusieurs centaines d'heures à [i]court terme[/i].
Est-ce qu'on peut leur reprocher de s'interroger sur ce problème? Je ne pense pas, parce que d'auters projets continuent (reiser4/ext3dev/gfs/fuse...) qui s'attachent chacun à un problème différent.
Comme il a été dit lors du kernel summit, VFS a été quasi stable pendant plusieurs années. Maturité? En tout cas chaque projet travaille de son côté, mais les apports de chacun peut être carrément la prochaine évolution du vfs, profitant à tout le monde.
[^] # Re: Humeur
Posté par mickabouille . En réponse à la dépêche Le futur des systèmes de fichiers discuté au Linux Filesystems Workshop 2006. Évalué à 1.
LVM c'est pour la [i]souplesse[/i], tu répartis tes fs/swaps/etc. (ya autre chose?) comme tu veux sur tes disques physiques, et tu peux même tout changer quand ça te plaît.
chunkfs c'est pour la [i]robustesse[/i], le fs apparent est découpé en entités autonomes. En casser une ne casse pas tout et en réparer une n'exige pas de démonter tout le fs.
Pour enfoncer le clou : on peut bien sûr utiliser les deux en même temps, créer des chunfs (constitué de plusieurs ext3/4/reiser/machinfs un peu modifiés) sur une partition crée en LVM.
Gardons en tête que chunkfs est un [i]proposition[/i] même pas implémentée (et peut ête ne le sera-t-elle jamais vraiment) qui répond à UN problème (qui d'ailleurs est bien décrit dans les liens, il faut les lire) : le fait que les tailles des disques augmente [i]beaucoup[/i] plus vite que 1. les temps d'accès (et aussi les vitesses de transfert mais ici c'est pas important) et 2. la vitesse des algos de fsck (qu'il ne prévoient pas de pouvoir augmenter d'un facteur 100), avec pour conséquence des temps de fsck de plusieurs centaines d'heures à [i]court terme[/i].
Est-ce qu'on peut leur reprocher de s'interroger sur ce problème? Je ne pense pas, parce que d'auters projets continuent (reiser4/ext3dev/gfs/fuse...) qui s'attachent chacun à un problème différent.
Comme il a été dit lors du kernel summit, VFS a été quasi stable pendant plusieurs années. Maturité? En tout cas chaque projet travaille de son côté, mais les apports de chacun peut être carrément la prochaine évolution du vfs, profitant à tout le monde.