Comment trouver la cause du système de fichiers principal en mode lecture seule
Ubuntu 12.04
Le système de fichiers passe fréquemment en mode lecture seule. Tout d'abord, j'ai lu cette question le système de fichiers passe fréquemment en mode lecture seule déjà. Mais je dois savoir si ce n'est pas causé par autre chose que dying hard drive. Ceci est un serveur fourni par mon client et j'exécute juste quelques node.js workers + un node.js server et j'utilise mongodb.
De temps en temps (toutes les 20 à 50 heures), le système rend soudainement le système de fichiers en lecture seule, le processus mongodb échoue (en raison de fs en lecture seule) et mes nœuds de travail/serveur (qui sont démarrés par forever) sont juste tués.
Voici le journal de dmesg - je peux y voir quelques erreurs et messages qui FS va en lecture seule, et il y a aussi une erreur JOURNAL mais je voudrais trouver la cause de ces erreurs ..
http://speedy.sh/Ux2VV/dmesg.log.txt
éditer
smartctl -t long /dev/sda
smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.5.0-23-generic] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net
SMART support is: Unavailable - device lacks SMART capability.
A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.
Qu'est ce que je fais mal? C'est la même chose pour sda2.
Morover maintenant quand je tape une commande qui n'existe pas dans Shell, j'obtiens ceci:
Sorry, command-not-found has crashed! Please file a bug report at:
https://bugs.launchpad.net/command-not-found/+filebug
Please include the following information with the report:
edit2
Je viens de recevoir des informations que ce serveur est en fait VPS et ils m'ont dit que les disques durs sont OK et qu'ils sont sur RAID 10. Et ils m'ont dit que "forcer fsck dans fstab devrait aider" ...
edit3
voici la sortie de la commande mount:
/dev/sda2 on / type ext4 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/Fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
none on /media/psf type prl_fs (rw,nosuid,nodev,sync,noatime,share,_netdev)
Il n'y a donc pas réellement de lecteur sda? Seulement sda2?
edit4
Sortie de fsck -N commande:
root@ubuntu:~# fsck -N sda
fsck from util-linux 2.20.1
[/sbin/fsck.ext4 (1) -- /] fsck.ext4 sda /dev/sda2
[26729.124569] Write(10): 2a 00 03 96 5a b0 00 00 08 00
[26729.124576] end_request: I/O error, dev sda, sector 60185264
[26729.125298] Buffer I/O error on device sda2, logical block 4593494
[26729.125986] lost page write due to I/O error on sda2
Pour moi, c'est une preuve assez forte que votre /dev/sda est en voie de disparition. Vous pouvez exécuter un test smartctl dessus pour confirmation (smartctl -t long /dev/sda), mais je serais enclin à le remplacer dès que possible.
Edit: la commande smartctl que j'ai donnée est correcte telle qu'elle est écrite. Merci d'avoir montré le mode d'échec dans votre question; cela ressemble soit à un matériel très ancien, soit à une sorte de couche de traduction: la virtualisation ou un contrôleur RAID matériel. Pouvez-vous clarifier?
Puis-je répéter mon affirmation selon laquelle votre disque dur est en train de disparaître? Les tests sont tous très bien, mais faire remplacer le matériel avant que votre système n'emballe et que vos données soient perdues devrait être votre priorité maintenant. S'il vous plaît, à tout le moins assurez-vous que vos sauvegardes sont complètement à jour avant de perdre plus de temps sur smartctl.
Edit 2: cela vaut certainement la peine d'essayer ce qu'ils ont suggéré - fscking le système de fichiers - mais j'ai peu d'espoir que cela résoudra le problème parce que votre FS isn ' t passer en mode ro en raison de FS incohérences, il passe en mode ro en raison de problèmes de communication avec le matériel sous-jacent.
S'ils ont la certitude que le matériel sous-jacent est correct, alors c'est un problème entre le noyau et le matériel, c'est-à-dire la couche de virtualisation. Vous devriez probablement demander à votre fournisseur VPS de confirmer que la distribution et la version exacte du noyau que vous exécutez sont entièrement prises en charge sur leur système VPS.
Un moyen plus parfait de trouver l'erreur exacte peut être pendant la période de lecture seule et d'exécuter la commande dmesg pour tout bogue/problème. Vous pouvez également essayer d'exécuter fsck en mode sec pour déterminer quel est le problème. (désolé en raison d'une restriction d'accès, je ne suis pas en mesure d'afficher votre pièce jointe. Si c'est pendant la période d'émission, je le vérifierai plus tard)
J'avais également rencontré le même problème, dans lequel le serveur FS allait en lecture seule. Faites une vérification de l'inode, ils pourraient probablement être pleins:
df -i