Jak znaleźć przyczynę przejścia głównego systemu plików do trybu tylko do odczytu

Ubuntu 12.04

System plików często przechodzi w tryb tylko do odczytu. Przede wszystkim przeczytałem, że system plików pytań już często przechodzi w tryb „tylko do odczytu” . Ale muszę wiedzieć, czy nie jest to spowodowane czymś innym niż dying hard drive. To jest serwer dostarczony przez mojego klienta i właśnie uruchamiam tam node.js workers+ jeden node.js serveri używam mongodb.

Od czasu do czasu (co 20-50 godzin) system nagle powoduje, że system plików jest tylko do odczytu, proces mongodb kończy się niepowodzeniem (z powodu fs tylko do odczytu), a moi pracownicy / serwer węzłów (przez których uruchamiany forever) są właśnie zabijani.

Oto dziennik z dmesg - widzę tam pewne błędy i komunikaty, które FS zamierza tylko do odczytu, i jest też błąd JOURNAL, ale chciałbym znaleźć przyczynę tych błędów.

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

edytować

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.

Co robię źle? To samo dotyczy sda2.

Teraz, gdy piszę dowolne polecenie, które nie istnieje w powłoce, otrzymuję to:

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:

edycja2

Właśnie dostałem informację, że ten serwer to tak naprawdę VPS, i powiedzieli mi, że dyski twarde są w porządku i są na RAID 10. I powiedzieli mi, że „wymuszenie fsck w fstab powinno pomóc” ...

edycja3

tutaj jest wyjście z mountpolecenia:

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

Więc właściwie nie ma napędu SDA? Tylko sda2?

edycja4

Dane wyjściowe fsck -Npolecenia:

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

Dla mnie to dość mocny dowód na to, że /dev/sdawłaśnie wychodzisz. Możesz uruchomić na nim test smartctl w celu potwierdzenia ( smartctl -t long /dev/sda), ale chciałbym go jak najszybciej wymienić.

Edycja : wydanesmartctl przeze mnie polecenie jest poprawne. Dziękujemy za pokazanie trybu awarii w pytaniu; wygląda na to, że masz bardzo stary sprzęt lub istnieje jakiś rodzaj warstwy translacyjnej: wirtualizacja lub sprzętowy kontroler RAID. Możesz wyjaśnić?

Czy mogę powtórzyć moje twierdzenie, że twój dysk twardy jest już w drodze? Testy przebiegają bardzo dobrze, ale wymiana sprzętu przed spakowaniem systemu i utratą danych powinna być teraz Twoim priorytetem. Proszę przynajmniej upewnić się, że kopie zapasowe są całkowicie up-to-date przed marnować więcej czasu smartctl.

Edycja 2 : z pewnością warto wypróbować to, co zasugerowali - fsckowanie systemu plików - ale mam małą nadzieję, że to rozwiąże problem, ponieważ twój FS nie przechodzi do trybu ro z powodu niespójności FS, to spada do trybu ro, ponieważ problemów z rozmawianiem z podstawowym sprzętem.

Jeśli mają pewność, że podstawowy sprzęt jest w porządku, to jest to problem między jądrem a sprzętem, tj. Warstwą wirtualizacji. Prawdopodobnie powinieneś poprosić swojego dostawcę VPS, aby potwierdził, że dystrybucja i dokładna wersja jądra, z której korzystasz, są w pełni obsługiwane w ich systemie VPS.

Bardziej idealnym sposobem na znalezienie dokładnego błędu może być okres tylko do odczytu i uruchomienie polecenia dmesgw przypadku błędów / problemów. Możesz także spróbować uruchomić fscktryb suchy, aby dowiedzieć się, na czym polega problem. (przepraszam z powodu ograniczeń dostępu nie mogę wyświetlić Twojego załącznika. Jeśli jest on w trakcie okresu wystawienia, sprawdzę go później)

Napotkałem również ten sam problem, w którym serwer FS przechodził w tryb tylko do odczytu. Sprawdź i-węzeł, prawdopodobnie mogą być pełne:

df -i