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 ce système de fichiers de questions passe souvent en mode lecture seule . 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'en lance juste un node.js workers+ un node.js serveret 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 simplement tués.

Voici le journal de dmesg - je peux y voir quelques erreurs et messages que FS va lire uniquement, 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 pareil pour sda2.

Morover maintenant quand je tape une commande qui n'existe pas dans le 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 mountcommande:

/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 la fsck -Ncommande:

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/sdaest sur le point de disparaître. 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 smartctlcommande 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. Veuillez au moins vous assurer que vos sauvegardes sont complètement à jour avant de perdre plus de temps 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 ne passe pas en mode ro en raison d'incohérences FS, il tombe en mode ro parce des 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 dmesgpour tout bogue / problème. Vous pouvez également essayer d'exécuter le fsckmode en mode sec pour déterminer 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 entrait en lecture seule. Faites une vérification de l'inode, ils pourraient probablement être pleins:

df -i