Как найти причину, по которой основная файловая система собирается в режим только для чтения

Ubuntu 12.04

Файловая система часто переходит в режим только для чтения. Прежде всего, я прочитал этот вопрос: файловая система уже часто переходит в режим только для чтения . Но я должен знать, не вызвано ли это чем-то еще dying hard drive. Это сервер предоставляется моим клиентом , и я просто подножки есть некоторые node.js workers+ один , node.js serverи я использую mongodb.

Время от времени (каждые 20-50 часов) система внезапно делает файловую систему доступной только для чтения, процесс mongodb завершается неудачно (из-за только для чтения fs), и мои рабочие / серверы узла (которые запускаются forever) просто уничтожаются.

Вот журнал от dmesg - я вижу там некоторые ошибки и сообщения, что FS собирается только для чтения, и есть также некоторая ошибка ЖУРНАЛА, но я хотел бы найти причину этих ошибок ..

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

редактировать

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.

Что я делаю не так? То же самое для sda2.

Теперь, когда я набираю любую команду, которая не существует в оболочке, я получаю это:

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

Я только что получил информацию, что этот сервер на самом деле является VPS, и они сказали мне, что с жесткими дисками все в порядке, и они на RAID 10. И они сказали мне, что «форсирование fsck в fstab должно помочь» ...

Edit3

вот вывод 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)

Значит нет на самом деле sda drive? Только sda2?

edit4

Выход из fsck -Nкоманды:

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

Для меня это довольно веское доказательство того, что ваш /dev/sdaвыход. Вы можете запустить тест smartctl для подтверждения ( smartctl -t long /dev/sda), но я бы хотел заменить его как можно скорее.

Изменить : smartctlкоманда, которую я дал, является правильным, как написано. Спасибо за показ режима отказа в вашем вопросе; похоже, либо у вас очень старое оборудование, либо есть какой-то уровень трансляции: либо виртуализация, либо аппаратный контроллер RAID. Вы можете уточнить?

Могу ли я повторить свое утверждение о том, что ваш жесткий диск находится на выходе? Тестирование все очень хорошо, но замена оборудования до того, как ваша система будет упакована и ваши данные будут потеряны, должна стать вашим приоритетом. Пожалуйста, по крайней мере, убедитесь, что ваши резервные копии полностью обновлены, прежде чем тратить больше времени smartctl.

Редактировать 2 : безусловно, стоит попробовать то, что они предложили - fscking файловой системы - но я мало надеюсь, что это решит проблему, потому что ваша FS не переходит в режим ro из-за несоответствий FS, она переходит в режим ro, потому что проблем, связанных с базовым оборудованием.

Если они уверены, что с базовым оборудованием все в порядке, то это проблема между ядром и оборудованием, то есть уровнем виртуализации. Вам, вероятно, следует попросить вашего провайдера VPS подтвердить, что дистрибутив и точная версия ядра, которую вы используете, полностью поддерживаются в их системе VPS.

Более совершенный способ найти точную ошибку может быть во время периода только для чтения и выполнить команду dmesgдля любых ошибок / проблем. Вы также можете попробовать запустить fsckв сухом режиме, чтобы выяснить, в чем проблема. (извините из-за ограничения доступа, я не могу просмотреть ваше вложение. Если оно будет в период выдачи, я проверю его позже)

Я также столкнулся с той же проблемой, когда сервер FS переходил только для чтения. Сделайте проверку inode, возможно, они переполнены:

df -i