Cómo encontrar la causa del sistema de archivos principal que va al modo de solo lectura

Ubuntu 12.04

El sistema de archivos pasa al modo de solo lectura con frecuencia. En primer lugar, he leído que este sistema de archivos de preguntas entra en modo de solo lectura con frecuencia . Pero tengo que saber si no es causado por otra cosa que no sea dying hard drive. Este es el servidor proporcionado por mi cliente y solo estoy ejecutando allí un node.js workers+ uno node.js servery estoy usando mongodb.

De vez en cuando (cada 20-50h) el sistema de repente hace que el sistema de archivos sea de solo lectura, el proceso mongodb falla (debido a fs de solo lectura) y mis servidores / trabajadores de nodo (que son iniciados por forever) son simplemente asesinados.

Aquí está el registro de dmesg: puedo ver algunos errores y mensajes que FS va a leer solo, y también hay un error de DIARIO, pero me gustaría encontrar la causa de esos errores.

http://speedy.sh/Ux2VV/dmesg.log.txt

editar

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.

¿Que estoy haciendo mal? Lo mismo es para sda2.

Ahora, cuando escribo cualquier comando que no existe en el shell, obtengo esto:

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

Acabo de recibir información de que este servidor es en realidad VPS y me dijeron que los discos duros están bien y que están en RAID 10. Y me dijeron que "forzar fsck en fstab debería ayudar" ...

edit3

aquí es salida del mountcomando:

/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)

Entonces, ¿no hay realmente una unidad sda? Sólo sda2?

edit4

Salida del fsck -Ncomando:

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

Para mí, esa es una evidencia bastante fuerte de que tu estás /dev/sdasaliendo. Podría ejecutar una prueba de smartctl para confirmarlo ( smartctl -t long /dev/sda), pero me inclinaría a reemplazarlo lo antes posible.

Editar : el smartctlcomando que le di es correcto como está escrito. Gracias por mostrar el modo de falla en su pregunta; Parece que tiene un hardware muy antiguo o hay algún tipo de capa de traducción en el camino: virtualización o un controlador RAID de hardware. ¿Puedes aclarar?

¿Puedo repetir mi afirmación de que su HDD está saliendo? Las pruebas están muy bien, pero reemplazar su hardware antes de que su sistema se empaquete y se pierdan sus datos debería ser su prioridad ahora. Por lo menos, asegúrese de que sus copias de seguridad estén completamente actualizadas antes de perder más tiempo smartctl.

Edición 2 : sin duda vale la pena probar lo que han sugerido: abrir el sistema de archivos, pero tengo pocas esperanzas de que eso solucione el problema porque su FS no está cayendo al modo ro debido a inconsistencias del FS, sino al modo ro porque de problemas para hablar con el hardware subyacente.

Si tienen confianza en que el hardware subyacente está bien, entonces es un problema entre el núcleo y el hardware, es decir, la capa de virtualización. Probablemente debería pedirle a su proveedor de VPS que confirme que la distribución y la versión exacta del kernel que está ejecutando son totalmente compatibles con su sistema VPS.

Una forma más perfecta de encontrar el error exacto puede ser durante el período de solo lectura y ejecutar el comando dmesgpara cualquier error / problema. También puede intentar ejecutar el fsckmodo seco para descubrir cuál es el problema. (perdón debido a la restricción de acceso, no puedo ver su archivo adjunto. Si es durante el período de emisión, lo comprobaré más adelante)

También me enfrenté al mismo problema, en el que el servidor FS entraba en solo lectura. Verifique el inodo, probablemente podrían estar llenos:

df -i