Làm thế nào để tìm nguyên nhân của hệ thống tập tin chính sẽ chỉ đọc chế độ

Ubuntu 12.04

Hệ thống tập tin chuyển sang chế độ chỉ đọc thường xuyên. Trước hết tôi đã đọc hệ thống tập tin câu hỏi này đang chuyển sang chế độ chỉ đọc thường xuyên . Nhưng tôi phải biết nếu nó không phải do một thứ khác gây ra dying hard drive. Đây là máy chủ được cung cấp bởi khách hàng của tôi và tôi chỉ đang chạy ở đó một số node.js workers+ một node.js servervà tôi đang sử dụng mongodb.

Thỉnh thoảng hệ thống (cứ sau 20-50h) đột nhiên làm cho hệ thống tập tin chỉ đọc, quá trình mongodb không thành công (do fs chỉ đọc) và công nhân / máy chủ nút của tôi (được khởi động bởi forever) bị giết.

Đây là nhật ký từ dmesg - Tôi có thể thấy có một số lỗi và thông báo rằng FS sẽ chỉ đọc, và cũng có một số lỗi JOURNAL nhưng tôi muốn tìm nguyên nhân của những lỗi đó ..

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

biên tập

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.

Tôi đang làm gì sai? Tương tự là cho sda2.

Bây giờ khi tôi gõ bất kỳ lệnh nào không tồn tại trong shell, tôi nhận được điều này:

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:

chỉnh sửa2

Tôi vừa nhận được thông tin rằng máy chủ này thực sự là VPS và họ nói với tôi rằng ổ cứng vẫn ổn và họ đang dùng RAID 10. Và họ nói với tôi rằng "buộc fsck trong fstab sẽ giúp" ...

chỉnh sửa3

đây là đầu ra từ mountlệnh:

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

Vì vậy, không có ổ đĩa sda thực sự? Chỉ sda2?

chỉnh sửa4

Đầu ra từ fsck -Nlệnh:

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

Đối với tôi, đó là bằng chứng khá mạnh mẽ rằng bạn /dev/sdađang trên đường ra. Bạn có thể chạy thử nghiệm smartctl trên đó để xác nhận ( smartctl -t long /dev/sda), nhưng tôi có xu hướng thay thế nó càng sớm càng tốt.

Chỉnh sửa : smartctllệnh tôi đã đưa ra là chính xác như được viết. Cảm ơn đã hiển thị chế độ thất bại trong câu hỏi của bạn; điều này có vẻ như bạn có phần cứng rất cũ hoặc có một loại lớp dịch theo cách: ảo hóa hoặc bộ điều khiển RAID phần cứng. Bạn có thể làm rõ?

Tôi có thể lặp lại khẳng định của mình rằng ổ cứng của bạn đang trên đường ra không? Kiểm tra tất cả đều rất tốt, nhưng việc thay thế phần cứng trước khi hệ thống của bạn đóng gói và dữ liệu của bạn bị mất nên là ưu tiên của bạn ngay bây giờ. Xin vui lòng, ít nhất hãy chắc chắn rằng các bản sao lưu của bạn hoàn toàn cập nhật trước khi lãng phí thêm thời gian smartctl.

Chỉnh sửa 2 : chắc chắn đáng để thử những gì họ đã đề xuất - tìm hiểu hệ thống tệp - nhưng tôi không hy vọng điều đó sẽ khắc phục được sự cố vì FS của bạn không chuyển sang chế độ ro vì sự không nhất quán của FS, vì nó giảm xuống chế độ ro vì vấn đề nói chuyện với phần cứng cơ bản.

Nếu họ tin tưởng rằng phần cứng bên dưới vẫn ổn, thì đó là vấn đề giữa kernel và phần cứng, tức là lớp ảo hóa. Có lẽ bạn nên nhờ nhà cung cấp VPS xác nhận rằng bản phân phối và phiên bản kernel chính xác mà bạn đang chạy được hỗ trợ đầy đủ trên hệ thống VPS của họ.

Cách hoàn hảo hơn để tìm ra lỗi chính xác có thể là trong khoảng thời gian chỉ đọc và chạy lệnh dmesgcho bất kỳ lỗi / vấn đề nào. Bạn cũng có thể thử chạy fsckở chế độ khô để tìm hiểu vấn đề là gì. (xin lỗi do hạn chế truy cập. Tôi không thể xem tệp đính kèm của bạn. Nếu trong thời gian phát hành, tôi sẽ kiểm tra lại sau)

Tôi cũng đã phải đối mặt với vấn đề tương tự, trong đó máy chủ FS sẽ chỉ đọc. Kiểm tra inode, chúng có thể có đầy đủ:

df -i