A la demande générale (!), je vais apporter plus de précisions à ma réponse à la question de Brice "pourquoi les développeurs de ZFS n'ont il pas utilisé un lvm -gestionnaire de volume - traditionnel en le séparant du FS". (comme c'est la cas actuellement dans toutes les architectures).
Merci beaucoup !
Pool de stockage. Avec un LVM classique, c'est impossible à effectuer. En effet le LVM classique impose une relation 1 FS pour 1 volume. Si on souhaite ajouter de l'espace disque pour deux FS, il devient alors nécessaire de partionner le disque supplémentaire et d'affecter ces partitions à chacun des volumes.
Si j'ai bien compris, il suffit de faire # vgextend my_volume_group /dev/hdn
pour ajouter le nouveau disque (/dev/hdn) puis #lvextend -L+1G /dev/my_volume_group/mysfs1
#lvextend -L+2G /dev/my_volume_group/mysfs2
pour ajouter de la place aux éventuelles "partitions logiques" (respectivement 1 et 2 gigas)
et enfin resize_reiserfs -f /dev/my_volume_group/mysfs1
xfs_growfs /dev/my_volume_group/mysfs2
pour prévenir le fs. Même pas besoin de démonter.
On pourrais facilement imaginer un frontend mais je trouve que le système actuel n'est pas horrible à utiliser.
Dans un système classique, quand vous avez 2 FS qui partage un même disque, vous êtes mort (les caches des FS ne sont pas commun et les io ne peuvent pas être réordonner sur la globalité du disque).
Si, elles peuvent être réordonées sur la globalité du disque. D'ailleurs elles le sont sous Linux. On peut même attribuer au processus une prioritée dans la file d'attente.
Malgré cela, si un FS détecte une erreur de checksum, le FS est incapable de la corriger et renvoie juste une erreur, car le LVM se contente de retourner le bloc qui arrivent en premier d'un des 2 disques (sans savoir que la données est erronée).
Ça me parrait impossible ce que tu dit : si Linux se comportait comme ça le raid n'aurait aucune utilité.
D'ailleurs le RAID n'est pas géré par LVM, mais par le sous-système de raid, distinct (encore une fois, c'est plus propre).
Renseignement pris, LVM peut même réallouer les blocks défaillants depuis un autre volume.
Désolé d'être un peu condescendant mais... tu est sûr de savoir de quoi tu parle?
Ça ne me convainc pas de l'interêt de ZFS tout ça.
[^] # Re: A coté de la plaque.
Posté par un_brice (site web personnel) . En réponse au journal ZFS. Évalué à 2.
Si j'ai bien compris, il suffit de faire
# vgextend my_volume_group /dev/hdn
pour ajouter le nouveau disque (/dev/hdn) puis
#lvextend -L+1G /dev/my_volume_group/mysfs1
#lvextend -L+2G /dev/my_volume_group/mysfs2
pour ajouter de la place aux éventuelles "partitions logiques" (respectivement 1 et 2 gigas)
et enfin
resize_reiserfs -f /dev/my_volume_group/mysfs1
xfs_growfs /dev/my_volume_group/mysfs2
pour prévenir le fs. Même pas besoin de démonter.
On pourrais facilement imaginer un frontend mais je trouve que le système actuel n'est pas horrible à utiliser.
Si, elles peuvent être réordonées sur la globalité du disque. D'ailleurs elles le sont sous Linux. On peut même attribuer au processus une prioritée dans la file d'attente.
Ça me parrait impossible ce que tu dit : si Linux se comportait comme ça le raid n'aurait aucune utilité.
D'ailleurs le RAID n'est pas géré par LVM, mais par le sous-système de raid, distinct (encore une fois, c'est plus propre).
Renseignement pris, LVM peut même réallouer les blocks défaillants depuis un autre volume.
Désolé d'être un peu condescendant mais... tu est sûr de savoir de quoi tu parle?
Ça ne me convainc pas de l'interêt de ZFS tout ça.