C'est en lien avec le post précédent. En cas de rebot sauvage (onduleur
vidé ou panic), fsck me demande systématiquement de réparer /var à la
main. Ben oui, c'est celui qui bouge le plus.
Il y aurait-il des paramètres particuliers pour que le FS soit plus
tolérant aux crashes ? Le journaling en particulier, peut-être ...
Pour info la sortie de tunefs -p
[root@valinor ~]# tunefs -p /var
tunefs: ACLs: (-a) disabled
tunefs: MAC multilabel: (-l) disabled
tunefs: soft updates: (-n) disabled
tunefs: gjournal: (-J) disabled
tunefs: maximum blocks per file in a cylinder group: (-e) 2048
tunefs: average file size: (-f) 16384
tunefs: average number of files in a directory: (-s) 64
tunefs: minimum percentage of free space: (-m) 8%
tunefs: optimization preference: (-o) time
tunefs: volume label: (-L)
« Les grandes personnes ne comprennent jamais rien toutes seules, et c'est fatigant, pour les enfants, de toujours leur donner des explications... » -- Antoine de Saint-Exupéry, Le Petit Prince
() ASCII ribbon campaign -- Against HTML e-mail / http://www.asciiribbon.org -- Against proprietary attachments
xavier@groumpf.org (Xavier) writes:
Il y aurait-il des paramètres particuliers pour que le FS soit plus
tolérant aux crashes ? Le journaling en particulier, peut-être ...
tunefs: soft updates: (-n) disabled
Je crois que les soft updates peuvent aider, entre autre. Sous
OpenBSD, c'est juste une option dans fstab sans modification du fs.
« Les grandes personnes ne comprennent jamais rien toutes seules, et
c'est fatigant, pour les enfants, de toujours leur donner des
explications... » -- Antoine de Saint-Exupéry, Le Petit Prince
() ASCII ribbon campaign -- Against HTML e-mail
/ http://www.asciiribbon.org -- Against proprietary attachments
« Les grandes personnes ne comprennent jamais rien toutes seules, et c'est fatigant, pour les enfants, de toujours leur donner des explications... » -- Antoine de Saint-Exupéry, Le Petit Prince
() ASCII ribbon campaign -- Against HTML e-mail / http://www.asciiribbon.org -- Against proprietary attachments
Patrick Lamaizière
Xavier :
Bonsoir,
C'est en lien avec le post précédent. En cas de rebot sauvage (onduleur vidé ou panic), fsck me demande systématiquement de réparer /var à la main. Ben oui, c'est celui qui bouge le plus.
Il y aurait-il des paramètres particuliers pour que le FS soit plus tolérant aux crashes ? Le journaling en particulier, peut-être ...
C'est le role des softupdates de faire en sorte que le FS soit toujours dans un état cohérent.
L'inconvénient c'est que les modifications peuvent prendre du temps à atteindre le disque (tu perds des infos mais le fs est cohérent). Ça se règle mais je ne me souviens plus comment...
(en attendant les softupdates journalisées ?)
J'avais trouvé un papier avec des réglages à faire sur UFS quand on hack le noyau -et qu'on provoque donc des panics- mais impossible de remettre la main dessus là.
Xavier :
Bonsoir,
C'est en lien avec le post précédent. En cas de rebot sauvage (onduleur
vidé ou panic), fsck me demande systématiquement de réparer /var à la
main. Ben oui, c'est celui qui bouge le plus.
Il y aurait-il des paramètres particuliers pour que le FS soit plus
tolérant aux crashes ? Le journaling en particulier, peut-être ...
C'est le role des softupdates de faire en sorte que le FS soit toujours
dans un état cohérent.
L'inconvénient c'est que les modifications peuvent prendre du temps à
atteindre le disque (tu perds des infos mais le fs est cohérent). Ça se
règle mais je ne me souviens plus comment...
(en attendant les softupdates journalisées ?)
J'avais trouvé un papier avec des réglages à faire sur UFS
quand on hack le noyau -et qu'on provoque donc des panics- mais
impossible de remettre la main dessus là.
C'est en lien avec le post précédent. En cas de rebot sauvage (onduleur vidé ou panic), fsck me demande systématiquement de réparer /var à la main. Ben oui, c'est celui qui bouge le plus.
Il y aurait-il des paramètres particuliers pour que le FS soit plus tolérant aux crashes ? Le journaling en particulier, peut-être ...
C'est le role des softupdates de faire en sorte que le FS soit toujours dans un état cohérent.
L'inconvénient c'est que les modifications peuvent prendre du temps à atteindre le disque (tu perds des infos mais le fs est cohérent). Ça se règle mais je ne me souviens plus comment...
(en attendant les softupdates journalisées ?)
J'avais trouvé un papier avec des réglages à faire sur UFS quand on hack le noyau -et qu'on provoque donc des panics- mais impossible de remettre la main dessus là.
