Як знайти причину роботи основної файлової системи в режимі лише для читання

Ubuntu 12.04

Файлова система часто переходить у режим лише для читання. Перш за все, я читав це питання файлової системи вже часто переходить у режим читання . Але я повинен знати, якщо це не викликано чимось іншим, ніж dying hard drive. Це сервер, наданий моїм клієнтом, і я просто запускаю там якийсь node.js workers+ один, node.js serverі я його використовую mongodb.

Час від часу (кожні 20-50 годин) система раптово змушує файлову систему читати лише, процес mongodb не вдається (через fs-only read), і мої працівники вузла / сервер (які запускаються 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:

редагувати2

Щойно я отримав інформацію про те, що цей сервер насправді VPS, і вони сказали мені, що жорсткі диски в порядку, і вони є на RAID 10. І вони мені сказали, що "примушування fsck у fstab повинно допомогти" ...

редагувати3

ось вихід з 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? Тільки sda2?

редагувати4

Виведення з 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