[Freebsd] Background fsck

Le
Patrick Lamaizière
'soir,

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.

Bref ça marche ou pas ?

Merci.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Ollivier Robert
Le #17510291
Dans l'article Patrick Lamaizi
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
Le #17516421
Ollivier Robert:

Dans l'article Patrick Lamaizi
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
Le #17521511
Dans l'article Patrick Lamaizière
** 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
Le #17522211
Ollivier Robert
Dans l'article Patrick Lamaizière >** 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
Le #17523211
Dans l'article Michel Talon
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
Le #17523341
Ollivier Robert écrivait

Dans l'article Michel Talon
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
Le #17523491
Dans l'article Patrick Lamaizière
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
Le #17524691
Ollivier Robert
>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
Le #17527761
Ollivier Robert
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.
Thierry Herbelot
Le #17528711
Michel Talon wrote:

Ollivier Robert
>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 :

vm.kmem_size_max="1024M"
vfs.zfs.arc_max="512M"
vfs.zfs.prefetch_disable="1"

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
Publicité
Poster une réponse
Anonyme