| View previous topic :: View next topic |
| Author |
Message |
versus8
Tux's lil' helper
Joined: 21 Sep 2005
Posts: 130
|
 Posted: Thu Aug 15, 2013 5:15 pm Post subject: [reiserfsck] Arrêt brutal système (Résolu) |
 |
|
Hello world ^^
Je me préoccupe beaucoup d'une machine qui ne reboot plus suite à un arrêt brutal du système. udev veut monter "/" en lecture-seule mais freeze (pas de message d'erreur ou de led "num-lock" qui clignoterait à cause d'un kernel-panic). Je pense que le montage en lecture-seule n'a d'autre objectif que de préparer la partition à un fsck.
Voici les faits antérieurs qui pourrait vous aider à me porter secours :
- je cuisine la distro en x686 sur un i7 --jobs=13 dans un environnement virtuel, et je fais également des binaires destinés à une machine plus faible, type Intel Atom 2*cores,
- j'utilise le tuto stage 5 de notre ami d2_racing, avec reset de la table de partition (avec dd) et partitionnement avec cfdisk (qui me propose en plus d'écrire sur la table qui est devenue vierge), puis je ré-installe grub,
- reiserfsck est quant à lui bien installé.
Environnement :
- +kernel-debug +printk-early +rc_logger +syslog +dmesg = tous actifs
- partitionnement simple : /dev/sda1 (root) et /dev/sda2 (swap)
Maintenant, le symptôme :
- message d'erreur opérationnel au boot, e2fsck (ou fsck) qui relève du "magical number" sur le super-block, ce qui n'empêche en rien le boot de la machine (sauf si reboot suite arrêt brutal du système). Celui-ci me propose la reconstruction du super-block (me semble t-il) via une commande que je n'ai pas pu retenir car le sysinit est trop rapide
Alors me vient beaucoup de questions :p
- la table et/ou le super-block sont-ils écrit sous un format ext2 pour que cela soit e2fsck qui vérifie ces derniers ?
- pourquoi un reiserfsck sous un environnement live-USB ne relève pas d'erreur de vérification du FS, pas plus pour le super-block ? Cependant, une vérification en lecture-seule permet par la suite au système de rebooter (toujours avec cet erreur opérationnel),
- dois-je prendre le risque de forcer la reconstruction du super-block (et de perdre beaucoup de temps) avec reiserfsck, ou dois-je prendre le risque (si risque il y a) d'exécuter la commande e2fsck proposée au boot ?
- quels sont les moyens préventifs pour éviter la reproduction de ce problème ?
Si vous souhaitez avoir d'autres informations, n'hésitez pas, car là j'ai un peu peur de perdre des données. Je ferais bien sur un autre stage5 préventif, cependant cela prend un certain temps (avec ou sans compression bz2 :p ). Mais j'éviterais de me lancer dans des manipulations risquées sans vos conseils avisés ^^
Par avance merci !
Last edited by versus8 on Thu Aug 22, 2013 12:56 am; edited 1 time in total |
|
| Back to top |
|
 |
boozo
Advocate
Joined: 01 Jul 2004
Posts: 3193
|
| Posted: Fri Aug 16, 2013 4:33 pm Post subject: |
|
|
'alute
Une question juste : reiser-3.6 au moins ? (et pas de /boot donc il est en reiser aussi ?)
| versus8 wrote: | Je me préoccupe beaucoup d'une machine qui ne reboot plus suite à un arrêt brutal du système.
(...)
- j'utilise le tuto stage 5 de notre ami d2_racing, avec reset de la table de partition (avec dd) et partitionnement avec cfdisk (qui me propose en plus d'écrire sur la table qui est devenue vierge), puis je ré-installe grub,
(...)
Maintenant, le symptôme :
- message d'erreur opérationnel au boot, e2fsck (ou fsck) qui relève du "magical number" sur le super-block, ce qui n'empêche en rien le boot de la machine (sauf si reboot suite arrêt brutal du système). Celui-ci me propose la reconstruction du super-block (me semble t-il) via une commande que je n'ai pas pu retenir car le sysinit est trop rapide
(...)
Cependant, une vérification en lecture-seule permet par la suite au système de rebooter (toujours avec cet erreur opérationnel)
(...) |
Je ne suis pas sûr d'avoir tout bien saisi désolé je comprends qu'il y a eu un arret brutal (type coupure courant) ayant mis le fs dans les choux mais depuis : le système boot ou pas ? 
Et Ensuite donc le #reiserfsck -check /ro_partition que tu as dû logiquement faire via un livecd n'a rien signalé d'anormal c'est çà ? (p.e. lancer un -fix-fixable ne t'a pas été proposé)
Sinon hormis les 2 options pré-citées, les rebuild-{sb,tree} ne sont pas eux sans conséquences donc oui dans tous les cas -> un stage4 préalable à l'une de ces 2 actions est nécessaire/OBLIGATOIRE 
Edit:
ps:/ Et d'autant plus quand on peut se prévaloir d'un i7 --jobs=13 plus la ram qui va avec ça va sans dire... alors si tu râles encore sur le temps système que ça prends, *dijù* je te colle mon p4 quelques semaines dans les pattes en guise de représailles 
_________________
" Un psychotique, c'est quelqu'un qui croit dur comme fer que 2 et 2 font 5, et qui en est pleinement satisfait.
Un névrosé, c'est quelqu'un qui sait pertinemment que 2 et 2 font 4, et ça le rend malade ! " |
|
| Back to top |
|
|
versus8
Tux's lil' helper
Joined: 21 Sep 2005
Posts: 130
|
| Posted: Mon Aug 19, 2013 11:35 pm Post subject: |
|
|
Salut boozo
Désolé pour ma réponse un peu tardive, mais j'ai un peu avancé de mon côté... Alors pour répondre à tes questions :
| boozo wrote: | | Une question juste : reiser-3.6 au moins ? (et pas de /boot donc il est en reiser aussi ?) |
| Code: | myhostname ~ # mkfs.reiserfs -V
mkfs.reiserfs 3.6.21 (2009 www.namesys.com) |
EDIT : oui /boot est aussi en reiserfs.
| boozo wrote: | | Je ne suis pas sûr d'avoir tout bien saisi désolé je comprends qu'il y a eu un arret brutal (type coupure courant) ayant mis le fs dans les choux mais depuis : le système boot ou pas ? |
Oui, le système boot bien, sans même passer par un Live-USB finalement. C'est juste que je n'ai pas de sortie du reiserfsck et donc je pensais que le système ne bootait plus.
Je m'en suis assuré avec un reboot (pour flusher les caches avec sync sur sda1) et une extinction brutale volontaire sur l'écran de login, puis au retour à l'écran de login :
| Code: | myhostname ~ # dmesg | grep sda
[ 0.000000] Kernel command line: real_root=/dev/sda1 quiet zram num_devices=2
[ 1.941494] PM: Checking hibernation image partition /dev/sda2
[ 1.980971] sd 1:0:0:0: [sda] 31522176 512-byte logical blocks: (16.1 GB/15.0 GiB)
[ 1.983162] sd 1:0:0:0: [sda] Write Protect is off
[ 1.983173] sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 1.983310] sd 1:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 1.990823] sda: sda1
[ 1.998835] sd 1:0:0:0: [sda] Attached SCSI disk
[ 3.640361] REISERFS (device sda1): found reiserfs format "3.6" with standard journal
[ 3.640394] REISERFS (device sda1): using ordered data mode
[ 3.641367] REISERFS (device sda1): journal params: device sda1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
[ 3.642186] REISERFS (device sda1): checking transaction log (sda1)
[ 26.404019] REISERFS (device sda1): replayed 5 transactions in 23 seconds
[ 26.826896] REISERFS (device sda1): Using r5 hash to sort names |
Le fsck fait donc bien son boulot, même si je ne le vois pas le faire au boot. Le problème c'est qu'il rejoue 5 transid en 23 secondes ! cela me paraît juste énorme ! J'imagine pourquoi cela met plus de temps (jusqu'à plus de 400 secondes !) lorsque j'utilise le suspend-to-ram et que le système n'a pas était redémarrer depuis +24h.
J'ai pourtant un SSD...
| Code: | myhostname ~ # grep bogo /proc/cpuinfo && hdparm -tT /dev/sda && grep MemTotal /proc/meminfo
bogomips : 3193.26
bogomips : 3193.26
/dev/sda:
Timing cached reads: 1224 MB in 2.00 seconds = 611.87 MB/sec
Timing buffered disk reads: 98 MB in 3.03 seconds = 32.30 MB/sec
MemTotal: 898528 kB |
Bon, apriori, ce SSD est un peu lent  Y'a aussi laptop-mode qui doit retarder les écritures sur le disque et la config du noyau en CONFIG_NO_HZ=y / CONFIG_RCU_FAST_NO_HZ=y (entre autres paramètres) pour préserver la batterie qui peuvent (peut-être) entrer en compte. Mais là, c'est juste horrible...
A la longue je pense désactiver tous les types de mise en veille pour restreindre le temps d'exécution d'un potentiel reiserfsck. Au pire je configurerai rc.conf avec rc_parallel.
Ou alors patcher le noyau avec BFS pour avoir un meilleur I/O scheduler ? si cela fonctionne bien, je pourrais peut-être voir avec sys-kernel/pf-sources qui est également patché tuxonice... aurais-tu déjà testé ce noyau (ou un autre qui pourrais être intéressant) ? si BFS est stable, je pense conserver mon noyau actuel mais juste le patcher avec BFS... si tu as des infos, je suis preneur ^^
Autre chose, j'ai vu quelque part sur le Net que les derniers noyaux Linux avait des améliorations pour le SSD (entre autre, l'utilisation d'un SSD pour l'utiliser comme un cache matériel. Mais bon, j'utilise zram comme tu as pu le constater.)
Mais zram n'a pas l'air très intéressant finalement :
| Code: | myhostname ~ # swapon -s
Nom de fichier Type Taille Utilisé Priorité
/dev/zram0 partition 262140 0 16383
/dev/zram1 partition 262140 0 16383
myhostname ~ # hdparm -tT /dev/zram0
/dev/zram0:
Timing cached reads: 1286 MB in 2.00 seconds = 643.40 MB/sec
Timing buffered disk reads: 26 MB in 3.07 seconds = 8.47 MB/sec |
Sauf que zram n'utilise pas le SSD, et comme il me semble que swaper sur un SSD n'est pas recommandé, il vaut mieux tout de même l'utiliser (surtout que la compression avec un ratio 3:1 compense pas mal).
Mais bon, je m'éloigne un peu du sujet :p car fsck ne monte pas la partition swap lorsqu'il s'exécute, ou alors j'ai tout faux et faudrait que je teste avec une partition swap sur le SSD avec une priorité inférieure à mes zram, juste pour tester, et après, si je peux le faire, je mettrai une priorité supérieure (là encore je vais chercher quelque part sur le net comment régler la chose).
Ou alors, une autre piste ..
| Code: | myhostname ~ # uname -a
Linux myhostname 3.8.13-gentoo #23 SMP PREEMPT Mon Aug 19 02:36:19 CEST 2013 i686 Intel(R) Atom(TM) CPU N270 @ 1.60GHz GenuineIntel GNU/Linux |
Mon noyau est celui de gentoo-sources, il doit dater d'octobre 2012... Est-il trop vieux ? peut-être qu'il n'implémente pas d'optimisation pour les SSD ?
| boozo wrote: | | Et Ensuite donc le #reiserfsck -check /ro_partition que tu as dû logiquement faire via un livecd n'a rien signalé d'anormal c'est çà ? (p.e. lancer un -fix-fixable ne t'a pas été proposé) |
J'ai juste fait un reiserfsck /dev/sda1 (par défaut, il vérifie la partoche en lecture-seule). Et non, il ne trouve pas d'erreur, car le symptôme est exactement le même que sur le système : c'est-à-dire que je n'ai pas de sortie du reiserfsck au live boot, ça reste "bloqué" sur "attemp to mount media on /dev/sda1 in ro" ou un truc dans le genre. Mais en réalité, notre bon vieux reiserfsck fait son travail en arrière plan (vérifié par dmesg), et c'est pour cela que je ne trouvais pas d'erreur en checkant la dite partition / .
Il est fort possible que l'image ISO du live-USB utilisé lors de l'installation du stage5, soit corrompue à ce niveau là (j'ai pas fait de vérification Digest-MD5 de l'image :p ) et que le symptôme se soit répliqué sur le système en question.
Peut-être qu'en reconstruisant la paquet sys-fs/reiserfsprogs cela débloquera la situation... mais j'y crois pas trop.
| boozo wrote: | | Sinon hormis les 2 options pré-citées, les rebuild-{sb,tree} ne sont pas eux sans conséquences donc oui dans tous les cas -> un stage4 préalable à l'une de ces 2 actions est nécessaire/OBLIGATOIRE |
En effet, mieux vaut prévenir que guérir :p
| boozo wrote: | Edit:
ps:/ Et d'autant plus quand on peut se prévaloir d'un i7 --jobs=13 plus la ram qui va avec ça va sans dire... alors si tu râles encore sur le temps système que ça prends, *dijù* je te colle mon p4 quelques semaines dans les pattes en guise de représailles |
Mais nan, c'est le SSD du nettop qui ... rooo ... nan rien
EDIT : apparemment le SSD serait de type NAND Flash : je vais ouvrir un autre topic :p |
|
| Back to top |
|
|
versus8
Tux's lil' helper
Joined: 21 Sep 2005
Posts: 130
|
| Posted: Thu Aug 22, 2013 12:55 am Post subject: |
|
|
| Bon, il y a bien un souci avec le SSD. Je tag le sujet en résolu, tant pis pour la sortie d'affichage, c'est pas trop grave... |
|
| Back to top |
|
|
versus8
Tux's lil' helper
Joined: 21 Sep 2005
Posts: 130
|
| Posted: Mon Aug 26, 2013 10:01 pm Post subject: |
|
|
EDIT :
Solution apportée : migration vers EXT4 mais oublie de mettre à jour fstab (dont le FS type /dev/sda1 était toujours réglé sur reiserfs  ). |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
French
