C'est censé marcher le background fsck sur de l'UFS ?
À chaque fois, si je fais un vrai fsck (en single user) derrière un
background fsck il me trouve des erreurs et j'ai l'impression que sur le
long terme ça fout la merde. J'ai fini par le désactiver.
C'est cens<E9> marcher le background fsck sur de l'UFS ?
Oui :)
à chaque fois, si je fais un vrai fsck (en single user) derrière un background fsck il me trouve des erreurs et j'ai l'impression que sur le long terme ça fout la merde. J'ai fini par le désactiver.
Quelle version ? 6 ou 7 ?
Il n'y a pas eu de changement fondamentaux dans 6, peut-être un peu plus dans 7, je ne suis pas sûr qu'elles soient au même niveau. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve -=- Soutenez les UNIX libres ! FreeBSD Linux NetBSD OpenBSD !
Dans l'article <Xns3D97705331C01plam@dave.invalid>,
Patrick Lamaizi<E8>re <patnews1@davenulle.org> disait :
C'est cens<E9> marcher le background fsck sur de l'UFS ?
Oui :)
à chaque fois, si je fais un vrai fsck (en single user) derrière un
background fsck il me trouve des erreurs et j'ai l'impression que sur le
long terme ça fout la merde. J'ai fini par le désactiver.
Quelle version ? 6 ou 7 ?
Il n'y a pas eu de changement fondamentaux dans 6, peut-être un peu plus
dans 7, je ne suis pas sûr qu'elles soient au même niveau.
--
Ollivier ROBERT -=- FreeBSD: The Power to Serve -=- roberto@FreeBSD.org
Soutenez les UNIX libres ! FreeBSD Linux NetBSD OpenBSD !
C'est cens<E9> marcher le background fsck sur de l'UFS ?
Oui :)
à chaque fois, si je fais un vrai fsck (en single user) derrière un background fsck il me trouve des erreurs et j'ai l'impression que sur le long terme ça fout la merde. J'ai fini par le désactiver.
Quelle version ? 6 ou 7 ?
Il n'y a pas eu de changement fondamentaux dans 6, peut-être un peu plus dans 7, je ne suis pas sûr qu'elles soient au même niveau. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve -=- Soutenez les UNIX libres ! FreeBSD Linux NetBSD OpenBSD !
Patrick Lamaizière
Ollivier Robert:
Dans l'article , Patrick Lamaizi<E8>re disait :
C'est cens<E9> marcher le background fsck sur de l'UFS ?
Oui :)
à chaque fois, si je fais un vrai fsck (en single user) derrière un background fsck il me trouve des erreurs et j'ai l'impression que sur le long terme ça fout la merde. J'ai fini par le désactiver.
Quelle version ? 6 ou 7 ?
Il n'y a pas eu de changement fondamentaux dans 6, peut-être un peu plus dans 7, je ne suis pas sûr qu'elles soient au même niveau.
Là je suis en 7 et en 8.
C'est 100 % reproductible.
Exemple: - je fais un hard reset d'une machine vmware 8-current-du-weekend. - fsck en background ... (j'attend la fin hein) - halt -p - reboot en single user - fsck ** /dev/ad0s1d ** Last Mounted on /tmp (...) ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? y
** dev/ad0s1e ** Last Mounted on /var (...) ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? y
Bref là j'ai eu que /usr et / sans erreur au fsck.
Pour le fait de savoir si ça fout la merde à long terme, je ne suis pas sûr. Mais j'ai eu des fichiers dans lost+found alors que c'est pas censé arriver avec les soft-updates.
Et vendredi dernier j'ai dépanné un portable en 7.0 où sysinstall avait carrément disparu (suite à un kernel panic), Pareil, même si le bg fsck avait fonctionné un vrai fsck voyait des errreurs.
Du coup je m'interroge ?
Ollivier Robert:
Dans l'article <Xns3D97705331C01plam@dave.invalid>,
Patrick Lamaizi<E8>re <patnews1@davenulle.org> disait :
C'est cens<E9> marcher le background fsck sur de l'UFS ?
Oui :)
à chaque fois, si je fais un vrai fsck (en single user) derrière un
background fsck il me trouve des erreurs et j'ai l'impression que sur le
long terme ça fout la merde. J'ai fini par le désactiver.
Quelle version ? 6 ou 7 ?
Il n'y a pas eu de changement fondamentaux dans 6, peut-être un peu plus
dans 7, je ne suis pas sûr qu'elles soient au même niveau.
Là je suis en 7 et en 8.
C'est 100 % reproductible.
Exemple:
- je fais un hard reset d'une machine vmware 8-current-du-weekend.
- fsck en background ... (j'attend la fin hein)
- halt -p
- reboot en single user
- fsck
** /dev/ad0s1d
** Last Mounted on /tmp
(...)
** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? y
** dev/ad0s1e
** Last Mounted on /var
(...)
** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? y
Bref là j'ai eu que /usr et / sans erreur au fsck.
Pour le fait de savoir si ça fout la merde à long terme, je ne suis pas
sûr. Mais j'ai eu des fichiers dans lost+found alors que c'est pas
censé arriver avec les soft-updates.
Et vendredi dernier j'ai dépanné un portable en 7.0 où sysinstall avait
carrément disparu (suite à un kernel panic), Pareil, même si le bg fsck
avait fonctionné un vrai fsck voyait des errreurs.
C'est cens<E9> marcher le background fsck sur de l'UFS ?
Oui :)
à chaque fois, si je fais un vrai fsck (en single user) derrière un background fsck il me trouve des erreurs et j'ai l'impression que sur le long terme ça fout la merde. J'ai fini par le désactiver.
Quelle version ? 6 ou 7 ?
Il n'y a pas eu de changement fondamentaux dans 6, peut-être un peu plus dans 7, je ne suis pas sûr qu'elles soient au même niveau.
Là je suis en 7 et en 8.
C'est 100 % reproductible.
Exemple: - je fais un hard reset d'une machine vmware 8-current-du-weekend. - fsck en background ... (j'attend la fin hein) - halt -p - reboot en single user - fsck ** /dev/ad0s1d ** Last Mounted on /tmp (...) ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? y
** dev/ad0s1e ** Last Mounted on /var (...) ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? y
Bref là j'ai eu que /usr et / sans erreur au fsck.
Pour le fait de savoir si ça fout la merde à long terme, je ne suis pas sûr. Mais j'ai eu des fichiers dans lost+found alors que c'est pas censé arriver avec les soft-updates.
Et vendredi dernier j'ai dépanné un portable en 7.0 où sysinstall avait carrément disparu (suite à un kernel panic), Pareil, même si le bg fsck avait fonctionné un vrai fsck voyait des errreurs.
Du coup je m'interroge ?
Ollivier Robert
Dans l'article , Patrick Lamaizière disait :
** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? y
Ca, c'est normal. Le système des soft-updates te garantit la cohérence des méta-données au niveau du FS ce qui veut que que la seule erreur possible (vu l'ordonnancement) est que des blocs libres n'étaient pas marqués en tant que tels.
Pour le fait de savoir si ça fout la merde à long terme, je ne suis pas sûr. Mais j'ai eu des fichiers dans lost+found alors que c'est pas censé arriver avec les soft-updates.
Et vendredi dernier j'ai dépanné un portable en 7.0 où sysinstall avait carrément disparu (suite à un kernel panic), Pareil, même si le bg fsck avait fonctionné un vrai fsck voyait des errreurs.
Oui mais panic, c'est panic, et le système des soft-updates n'a plus sa place à ce moment là...
Du coup je m'interroge ?
Personnellement depuis les SU (et même avant) je n'ai pas perdu de fichiers (et je tourne current depuis 2.0...).
Mias ZFS c'est bien, mangez-en ! ;-) -- Ollivier ROBERT -=- FreeBSD: The Power to Serve -=- Soutenez les UNIX libres ! FreeBSD Linux NetBSD OpenBSD !
Dans l'article <Xns8B06CC2861967plam@dave.invalid>,
Patrick Lamaizière <patnews1@davenulle.org> disait :
** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? y
Ca, c'est normal. Le système des soft-updates te garantit la cohérence des
méta-données au niveau du FS ce qui veut que que la seule erreur possible (vu
l'ordonnancement) est que des blocs libres n'étaient pas marqués en tant que
tels.
Pour le fait de savoir si ça fout la merde à long terme, je ne suis pas
sûr. Mais j'ai eu des fichiers dans lost+found alors que c'est pas
censé arriver avec les soft-updates.
Et vendredi dernier j'ai dépanné un portable en 7.0 où sysinstall avait
carrément disparu (suite à un kernel panic), Pareil, même si le bg fsck
avait fonctionné un vrai fsck voyait des errreurs.
Oui mais panic, c'est panic, et le système des soft-updates n'a plus sa place
à ce moment là...
Du coup je m'interroge ?
Personnellement depuis les SU (et même avant) je n'ai pas perdu de fichiers
(et je tourne current depuis 2.0...).
Mias ZFS c'est bien, mangez-en ! ;-)
--
Ollivier ROBERT -=- FreeBSD: The Power to Serve -=- roberto@FreeBSD.org
Soutenez les UNIX libres ! FreeBSD Linux NetBSD OpenBSD !
** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? y
Ca, c'est normal. Le système des soft-updates te garantit la cohérence des méta-données au niveau du FS ce qui veut que que la seule erreur possible (vu l'ordonnancement) est que des blocs libres n'étaient pas marqués en tant que tels.
Pour le fait de savoir si ça fout la merde à long terme, je ne suis pas sûr. Mais j'ai eu des fichiers dans lost+found alors que c'est pas censé arriver avec les soft-updates.
Et vendredi dernier j'ai dépanné un portable en 7.0 où sysinstall avait carrément disparu (suite à un kernel panic), Pareil, même si le bg fsck avait fonctionné un vrai fsck voyait des errreurs.
Oui mais panic, c'est panic, et le système des soft-updates n'a plus sa place à ce moment là...
Du coup je m'interroge ?
Personnellement depuis les SU (et même avant) je n'ai pas perdu de fichiers (et je tourne current depuis 2.0...).
Mias ZFS c'est bien, mangez-en ! ;-) -- Ollivier ROBERT -=- FreeBSD: The Power to Serve -=- Soutenez les UNIX libres ! FreeBSD Linux NetBSD OpenBSD !
talon
Ollivier Robert wrote:
Dans l'article , Patrick Lamaizière disait : >** Phase 5 - Check Cyl groups >FREE BLK COUNT(S) WRONG IN SUPERBLK >SALVAGE? y
Ca, c'est normal. Le système des soft-updates te garantit la cohérence des méta-données au niveau du FS ce qui veut que que la seule erreur possible (vu l'ordonnancement) est que des blocs libres n'étaient pas marqués en tant que tels.
Ca c'est la théorie ... en pratique le disque peut réordonner les écritures, et toutes les belles garanties de SU s'envolent. C'est ce qui explique les histoires qu'on lit dans les mailing lists, au sujet de dommages plus importants que la simple récupération de blocs libres. Heureusement ceci est très rare, ça ne m'est arrivé qu'une fois. Pour être sûr que softupdates tourne comme prévu il faut inhiber le "write cache" du disque, et alors adieu les performances.
Oui mais panic, c'est panic, et le système des soft-updates n'a plus sa place à ce moment là...
Si, en théorie, oui, puisque jusqu'à la panique, les écritures sur le disque se font dans un ordre garantissant la cohérence du système de fichiers, et au moment de la panique, l'OS ne lance plus aucune écriture sur le disque. Le problème, c'est ce qui a été accumulé dans le cache du disque et qui va être écrit dans un désordre géré uniquement par le contrôleur du disque en fonction de ses propres algorithmes.
Ceci, plus le problème du fsck qui reste nécessaire pour récupérer les blocs libres montre que les SoftUpdates ont été un très mauvais choix de conception, par rapport à un système journalisé, beaucoup plus simple à implémenter, et somme toute aussi performant et plus sûr.
>Du coup je m'interroge ?
Personnellement depuis les SU (et même avant) je n'ai pas perdu de fichiers (et je tourne current depuis 2.0...).
Moi non plus, jamais perdu de fichier.
Mias ZFS c'est bien, mangez-en ! ;-)
ZFS c'est aussi une solution ultra compliquée, encore plus que SoftUpdates, donc il risque fort d'y avoir des cadavres dans les placards.
--
Michel TALON
Ollivier Robert <roberto@removethis.eu.org> wrote:
Dans l'article <Xns8B06CC2861967plam@dave.invalid>,
Patrick Lamaizière <patnews1@davenulle.org> disait :
>** Phase 5 - Check Cyl groups
>FREE BLK COUNT(S) WRONG IN SUPERBLK
>SALVAGE? y
Ca, c'est normal. Le système des soft-updates te garantit la cohérence des
méta-données au niveau du FS ce qui veut que que la seule erreur possible (vu
l'ordonnancement) est que des blocs libres n'étaient pas marqués en tant que
tels.
Ca c'est la théorie ... en pratique le disque peut réordonner les
écritures, et toutes les belles garanties de SU s'envolent. C'est ce qui
explique les histoires qu'on lit dans les mailing lists, au sujet de
dommages plus importants que la simple récupération de blocs libres.
Heureusement ceci est très rare, ça ne m'est arrivé qu'une fois.
Pour être sûr que softupdates tourne comme prévu il faut inhiber le
"write cache" du disque, et alors adieu les performances.
Oui mais panic, c'est panic, et le système des soft-updates n'a plus sa place
à ce moment là...
Si, en théorie, oui, puisque jusqu'à la panique, les écritures sur le
disque se font dans un ordre garantissant la cohérence du système de
fichiers, et au moment de la panique, l'OS ne lance plus aucune
écriture sur le disque. Le problème, c'est ce qui a été accumulé dans le
cache du disque et qui va être écrit dans un désordre géré uniquement
par le contrôleur du disque en fonction de ses propres algorithmes.
Ceci, plus le problème du fsck qui reste nécessaire pour récupérer les
blocs libres montre que les SoftUpdates ont été un très mauvais choix de
conception, par rapport à un système journalisé, beaucoup plus simple à
implémenter, et somme toute aussi performant et plus sûr.
>Du coup je m'interroge ?
Personnellement depuis les SU (et même avant) je n'ai pas perdu de fichiers
(et je tourne current depuis 2.0...).
Moi non plus, jamais perdu de fichier.
Mias ZFS c'est bien, mangez-en ! ;-)
ZFS c'est aussi une solution ultra compliquée, encore plus que
SoftUpdates, donc il risque fort d'y avoir des cadavres dans les
placards.
Dans l'article , Patrick Lamaizière disait : >** Phase 5 - Check Cyl groups >FREE BLK COUNT(S) WRONG IN SUPERBLK >SALVAGE? y
Ca, c'est normal. Le système des soft-updates te garantit la cohérence des méta-données au niveau du FS ce qui veut que que la seule erreur possible (vu l'ordonnancement) est que des blocs libres n'étaient pas marqués en tant que tels.
Ca c'est la théorie ... en pratique le disque peut réordonner les écritures, et toutes les belles garanties de SU s'envolent. C'est ce qui explique les histoires qu'on lit dans les mailing lists, au sujet de dommages plus importants que la simple récupération de blocs libres. Heureusement ceci est très rare, ça ne m'est arrivé qu'une fois. Pour être sûr que softupdates tourne comme prévu il faut inhiber le "write cache" du disque, et alors adieu les performances.
Oui mais panic, c'est panic, et le système des soft-updates n'a plus sa place à ce moment là...
Si, en théorie, oui, puisque jusqu'à la panique, les écritures sur le disque se font dans un ordre garantissant la cohérence du système de fichiers, et au moment de la panique, l'OS ne lance plus aucune écriture sur le disque. Le problème, c'est ce qui a été accumulé dans le cache du disque et qui va être écrit dans un désordre géré uniquement par le contrôleur du disque en fonction de ses propres algorithmes.
Ceci, plus le problème du fsck qui reste nécessaire pour récupérer les blocs libres montre que les SoftUpdates ont été un très mauvais choix de conception, par rapport à un système journalisé, beaucoup plus simple à implémenter, et somme toute aussi performant et plus sûr.
>Du coup je m'interroge ?
Personnellement depuis les SU (et même avant) je n'ai pas perdu de fichiers (et je tourne current depuis 2.0...).
Moi non plus, jamais perdu de fichier.
Mias ZFS c'est bien, mangez-en ! ;-)
ZFS c'est aussi une solution ultra compliquée, encore plus que SoftUpdates, donc il risque fort d'y avoir des cadavres dans les placards.
--
Michel TALON
Ollivier Robert
Dans l'article <gd1lb6$2ouc$, Michel Talon disait :
Pour être sûr que softupdates tourne comme prévu il faut inhiber le "write cache" du disque, et alors adieu les performances.
C'est le point que j'ai oublié d'inclure dans mon article, merci Michel.
Soit le disque a un système de tag (tagged queuing) et alors on peut avoir le cache en écriture à 1 (disques SCSI et SAS plus certains SATA modernes) sinon oui, il faut l'avoir à 0 (ce que personne ne fait vu que ça tue les perfs).
ZFS c'est aussi une solution ultra compliquée, encore plus que SoftUpdates, donc il risque fort d'y avoir des cadavres dans les placards.
À mettre en oeuvre, c'est très simple. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve -=- Soutenez les UNIX libres ! FreeBSD Linux NetBSD OpenBSD !
Dans l'article <gd1lb6$2ouc$1@asmodee.lpthe.jussieu.fr>,
Michel Talon <talon@lpthe.jussieu.fr> disait :
Pour être sûr que softupdates tourne comme prévu il faut inhiber le
"write cache" du disque, et alors adieu les performances.
C'est le point que j'ai oublié d'inclure dans mon article, merci Michel.
Soit le disque a un système de tag (tagged queuing) et alors on peut avoir le
cache en écriture à 1 (disques SCSI et SAS plus certains SATA modernes) sinon
oui, il faut l'avoir à 0 (ce que personne ne fait vu que ça tue les perfs).
ZFS c'est aussi une solution ultra compliquée, encore plus que
SoftUpdates, donc il risque fort d'y avoir des cadavres dans les
placards.
À mettre en oeuvre, c'est très simple.
--
Ollivier ROBERT -=- FreeBSD: The Power to Serve -=- roberto@FreeBSD.org
Soutenez les UNIX libres ! FreeBSD Linux NetBSD OpenBSD !
Dans l'article <gd1lb6$2ouc$, Michel Talon disait :
Pour être sûr que softupdates tourne comme prévu il faut inhiber le "write cache" du disque, et alors adieu les performances.
C'est le point que j'ai oublié d'inclure dans mon article, merci Michel.
Soit le disque a un système de tag (tagged queuing) et alors on peut avoir le cache en écriture à 1 (disques SCSI et SAS plus certains SATA modernes) sinon oui, il faut l'avoir à 0 (ce que personne ne fait vu que ça tue les perfs).
ZFS c'est aussi une solution ultra compliquée, encore plus que SoftUpdates, donc il risque fort d'y avoir des cadavres dans les placards.
À mettre en oeuvre, c'est très simple. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve -=- Soutenez les UNIX libres ! FreeBSD Linux NetBSD OpenBSD !
Patrick Lamaizière
Ollivier Robert écrivait
Dans l'article <gd1lb6$2ouc$, Michel Talon disait :
Pour être sûr que softupdates tourne comme prévu il faut inhiber le "write cache" du disque, et alors adieu les performances.
C'est le point que j'ai oublié d'inclure dans mon article, merci Michel
Ok merci pour les explications, comment on désactive le write cache ?
Soit le disque a un système de tag (tagged queuing) et alors on peut avoir le cache en écriture à 1 (disques SCSI et SAS plus certains SATA modernes) sinon oui, il faut l'avoir à 0 (ce que personne ne fait vu que ça tue les perfs).
ZFS c'est aussi une solution ultra compliquée, encore plus que SoftUpdates, donc il risque fort d'y avoir des cadavres dans les placards.
À mettre en oeuvre, c'est très simple.
ZFS m'a l'air un peu trop expérimental. J'utilise gjournal pour l'instant, pas eu de soucis particulier.
Ollivier Robert écrivait
Dans l'article <gd1lb6$2ouc$1@asmodee.lpthe.jussieu.fr>,
Michel Talon <talon@lpthe.jussieu.fr> disait :
Pour être sûr que softupdates tourne comme prévu il faut inhiber le
"write cache" du disque, et alors adieu les performances.
C'est le point que j'ai oublié d'inclure dans mon article, merci
Michel
Ok merci pour les explications, comment on désactive le write cache ?
Soit le disque a un système de tag (tagged queuing) et alors on peut
avoir le cache en écriture à 1 (disques SCSI et SAS plus certains SATA
modernes) sinon oui, il faut l'avoir à 0 (ce que personne ne fait vu
que ça tue les perfs).
ZFS c'est aussi une solution ultra compliquée, encore plus que
SoftUpdates, donc il risque fort d'y avoir des cadavres dans les
placards.
À mettre en oeuvre, c'est très simple.
ZFS m'a l'air un peu trop expérimental. J'utilise gjournal pour l'instant,
pas eu de soucis particulier.
Dans l'article <gd1lb6$2ouc$, Michel Talon disait :
Pour être sûr que softupdates tourne comme prévu il faut inhiber le "write cache" du disque, et alors adieu les performances.
C'est le point que j'ai oublié d'inclure dans mon article, merci Michel
Ok merci pour les explications, comment on désactive le write cache ?
Soit le disque a un système de tag (tagged queuing) et alors on peut avoir le cache en écriture à 1 (disques SCSI et SAS plus certains SATA modernes) sinon oui, il faut l'avoir à 0 (ce que personne ne fait vu que ça tue les perfs).
ZFS c'est aussi une solution ultra compliquée, encore plus que SoftUpdates, donc il risque fort d'y avoir des cadavres dans les placards.
À mettre en oeuvre, c'est très simple.
ZFS m'a l'air un peu trop expérimental. J'utilise gjournal pour l'instant, pas eu de soucis particulier.
Ollivier Robert
Dans l'article , Patrick Lamaizière disait :
Ok merci pour les explications, comment on désactive le write cache ?
Pour les disques ATA/SATA, dans /boot/loader.conf, cf ata(4) :
hw.ata.wc=0
ZFS m'a l'air un peu trop expérimental. J'utilise gjournal pour l'instant, pas eu de soucis particulier.
Aussi mais on retombe dans les limitations inhérentes à UFS. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve -=- Soutenez les UNIX libres ! FreeBSD Linux NetBSD OpenBSD !
Dans l'article <Xns9B377EFC68B72plam@91.121.44.19>,
Patrick Lamaizière <patnews1@davenulle.org> disait :
Ok merci pour les explications, comment on désactive le write cache ?
Pour les disques ATA/SATA, dans /boot/loader.conf, cf ata(4) :
hw.ata.wc=0
ZFS m'a l'air un peu trop expérimental. J'utilise gjournal pour l'instant,
pas eu de soucis particulier.
Aussi mais on retombe dans les limitations inhérentes à UFS.
--
Ollivier ROBERT -=- FreeBSD: The Power to Serve -=- roberto@FreeBSD.org
Soutenez les UNIX libres ! FreeBSD Linux NetBSD OpenBSD !
Ok merci pour les explications, comment on désactive le write cache ?
Pour les disques ATA/SATA, dans /boot/loader.conf, cf ata(4) :
hw.ata.wc=0
ZFS m'a l'air un peu trop expérimental. J'utilise gjournal pour l'instant, pas eu de soucis particulier.
Aussi mais on retombe dans les limitations inhérentes à UFS. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve -=- Soutenez les UNIX libres ! FreeBSD Linux NetBSD OpenBSD !
talon
Ollivier Robert wrote:
>ZFS c'est aussi une solution ultra compliquée, encore plus que >SoftUpdates, donc il risque fort d'y avoir des cadavres dans les >placards.
À mettre en oeuvre, c'est très simple.
Certes, je l'ai essayé moi aussi, sur un x386 avec 1 Gig de mémoire et je n'ai eu aucun des problèmes que les gens ont mentionnés. La souplesse et la commodité du bestiau sont ébouriffantes, il est clair que ça démode d'un coup tout ce qui existait avant. Mais que ce soit compliqué (pas à utiliser, dans sa programmation) est indéniable, ce qui laisse supposer qu'il y a un risque de trouver des termites dans la charpente, si tu voix ce que je veux dire ...
--
Michel TALON
Ollivier Robert <roberto@removethis.eu.org> wrote:
>ZFS c'est aussi une solution ultra compliquée, encore plus que
>SoftUpdates, donc il risque fort d'y avoir des cadavres dans les
>placards.
À mettre en oeuvre, c'est très simple.
Certes, je l'ai essayé moi aussi, sur un x386 avec 1 Gig de mémoire et
je n'ai eu aucun des problèmes que les gens ont mentionnés. La souplesse
et la commodité du bestiau sont ébouriffantes, il est clair que ça
démode d'un coup tout ce qui existait avant. Mais que ce soit compliqué
(pas à utiliser, dans sa programmation) est indéniable, ce qui laisse
supposer qu'il y a un risque de trouver des termites dans la charpente,
si tu voix ce que je veux dire ...
>ZFS c'est aussi une solution ultra compliquée, encore plus que >SoftUpdates, donc il risque fort d'y avoir des cadavres dans les >placards.
À mettre en oeuvre, c'est très simple.
Certes, je l'ai essayé moi aussi, sur un x386 avec 1 Gig de mémoire et je n'ai eu aucun des problèmes que les gens ont mentionnés. La souplesse et la commodité du bestiau sont ébouriffantes, il est clair que ça démode d'un coup tout ce qui existait avant. Mais que ce soit compliqué (pas à utiliser, dans sa programmation) est indéniable, ce qui laisse supposer qu'il y a un risque de trouver des termites dans la charpente, si tu voix ce que je veux dire ...
--
Michel TALON
xavier
Ollivier Robert wrote:
Mias ZFS c'est bien, mangez-en ! ;-)
Mouais... quand ça sera sec (surtout en 32 bits). Je suis revenu en arrière sur toutes les machines où je l'avais déployé, sauf une (pour cause de plein de petits disques SCSI)
Bon, en plus cette machine est en STABLE (7.1-PRERELEASE) et ça semble s'être amélioré. En tout cas, il y a eu des commits dans STABLE, pas dans RELEASE.
Par contre, une fois qu'on a pigé le concept, c'est simplissime à mettre en oeuvre, et d'une souplesse qui ramène les fastidieux calculs de disklabel à l'âge de pierre :-)
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear.
Ollivier Robert <roberto@REMOVETHIS.eu.org> wrote:
Mias ZFS c'est bien, mangez-en ! ;-)
Mouais... quand ça sera sec (surtout en 32 bits). Je suis revenu en
arrière sur toutes les machines où je l'avais déployé, sauf une (pour
cause de plein de petits disques SCSI)
Bon, en plus cette machine est en STABLE (7.1-PRERELEASE) et ça semble
s'être amélioré. En tout cas, il y a eu des commits dans STABLE, pas
dans RELEASE.
Par contre, une fois qu'on a pigé le concept, c'est simplissime à mettre
en oeuvre, et d'une souplesse qui ramène les fastidieux calculs de
disklabel à l'âge de pierre :-)
--
XAv
In your pomp and all your glory you're a poorer man than me,
as you lick the boots of death born out of fear.
Mouais... quand ça sera sec (surtout en 32 bits). Je suis revenu en arrière sur toutes les machines où je l'avais déployé, sauf une (pour cause de plein de petits disques SCSI)
Bon, en plus cette machine est en STABLE (7.1-PRERELEASE) et ça semble s'être amélioré. En tout cas, il y a eu des commits dans STABLE, pas dans RELEASE.
Par contre, une fois qu'on a pigé le concept, c'est simplissime à mettre en oeuvre, et d'une souplesse qui ramène les fastidieux calculs de disklabel à l'âge de pierre :-)
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear.
Thierry Herbelot
Michel Talon wrote:
Ollivier Robert wrote:
>ZFS c'est aussi une solution ultra compliquée, encore plus que >SoftUpdates, donc il risque fort d'y avoir des cadavres dans les >placards.
À mettre en oeuvre, c'est très simple.
Certes, je l'ai essayé moi aussi, sur un x386 avec 1 Gig de mémoire et je n'ai eu aucun des problèmes que les gens ont mentionnés. La souplesse et la commodité du bestiau sont ébouriffantes, il est clair que ça démode d'un coup tout ce qui existait avant. Mais que ce soit compliqué (pas à utiliser, dans sa programmation) est indéniable, ce qui laisse supposer qu'il y a un risque de trouver des termites dans la charpente, si tu voix ce que je veux dire ...
j'utilise ZFS de façon intensive au boulot (i386 + 2Go) et après un flou sur les réglages, j'ai une config _très_ stable :
il faut 2G de kmem (dont recompiler GENERIC avec le bon "options KVA_PAGESQ2")
puis débrayer le prefetch et borner l'utilisation de la RAM par ARC :
c'est mieux d'utiliser un kernel AMD64, mais y'en a des qui voudraient bien, mais qui peuvent pas
(par ailleurs, j'ai esssayé de dumper un files system UFS2 sur un disque 1To et .... "rendez-moi Zfs !")
TfH
-- retirez les "------%------" pour une adresse correcte
Michel Talon wrote:
Ollivier Robert <roberto@removethis.eu.org> wrote:
>ZFS c'est aussi une solution ultra compliquée, encore plus que
>SoftUpdates, donc il risque fort d'y avoir des cadavres dans les
>placards.
À mettre en oeuvre, c'est très simple.
Certes, je l'ai essayé moi aussi, sur un x386 avec 1 Gig de mémoire et
je n'ai eu aucun des problèmes que les gens ont mentionnés. La souplesse
et la commodité du bestiau sont ébouriffantes, il est clair que ça
démode d'un coup tout ce qui existait avant. Mais que ce soit compliqué
(pas à utiliser, dans sa programmation) est indéniable, ce qui laisse
supposer qu'il y a un risque de trouver des termites dans la charpente,
si tu voix ce que je veux dire ...
j'utilise ZFS de façon intensive au boulot (i386 + 2Go) et après un flou sur
les réglages, j'ai une config _très_ stable :
il faut 2G de kmem (dont recompiler GENERIC avec le bon "options
KVA_PAGESQ2")
puis débrayer le prefetch et borner l'utilisation de la RAM par ARC :
>ZFS c'est aussi une solution ultra compliquée, encore plus que >SoftUpdates, donc il risque fort d'y avoir des cadavres dans les >placards.
À mettre en oeuvre, c'est très simple.
Certes, je l'ai essayé moi aussi, sur un x386 avec 1 Gig de mémoire et je n'ai eu aucun des problèmes que les gens ont mentionnés. La souplesse et la commodité du bestiau sont ébouriffantes, il est clair que ça démode d'un coup tout ce qui existait avant. Mais que ce soit compliqué (pas à utiliser, dans sa programmation) est indéniable, ce qui laisse supposer qu'il y a un risque de trouver des termites dans la charpente, si tu voix ce que je veux dire ...
j'utilise ZFS de façon intensive au boulot (i386 + 2Go) et après un flou sur les réglages, j'ai une config _très_ stable :
il faut 2G de kmem (dont recompiler GENERIC avec le bon "options KVA_PAGESQ2")
puis débrayer le prefetch et borner l'utilisation de la RAM par ARC :
