Nguyên nhân gây hư hỏng hệ thống tập tin lớn đột ngột? (Inode gốc của không phải là một thư mục.) [Đã đóng]

Tôi có một máy tính xách tay chạy Maverick (rất hạnh phúc cho đến ngày hôm qua), với ổ SSD Patriot Torx; Mã hóa LUKS của toàn bộ phân vùng; một khối lượng vật lý lvm trên đó; sau đó về nhà và root trong khối lượng logic ext4 trên đó.

Khi tôi cố gắng khởi động nó ngày hôm qua, nó đã phàn nàn rằng nó không thể gắn kết hệ thống tập tin gốc. Chạy fsck, về cơ bản mọi inode dường như đều sai. Cả hai hệ thống tập tin nhà và gốc cho thấy vấn đề tương tự. Kiểm tra một siêu dự phòng không giúp được gì.

e2fsck 1.41.12 (17-May-2010)
lithe_root was not cleanly unmounted, check forced.
Resize inode not valid.  Recreate? no

Pass 1: Checking inodes, blocks, and sizes
Root inode is not a directory.  Clear? no   
Root inode has dtime set (probably due to old mke2fs).  Fix? no
Inode 2 is in use, but has dtime set.  Fix? no
Inode 2 has a extra size (4730) which is invalid
Fix? no
Inode 2 has compression flag set on filesystem without compression support.  Clear? no
Inode 2 has INDEX_FL flag set but is not a directory.
Clear HTree index? no
HTREE directory inode 2 has an invalid root node.
Clear HTree index? no
Inode 2, i_size is 9581392125871137995, should be 0.  Fix? no
Inode 2, i_blocks is 40456527802719, should be 0.  Fix? no
Reserved inode 3 (<The ACL index inode>) has invalid mode.  Clear? no
Inode 3 has compression flag set on filesystem without compression support.  Clear? no
Inode 3 has INDEX_FL flag set but is not a directory.
Clear HTree index? no
....

Chạy stringstrên các hệ thống tập tin, tôi có thể thấy có những tên giống như tên tệp và dữ liệu người dùng ở đó. Tôi có các bản sao lưu đủ tốt (chạm gỗ) mà không đáng để mò mẫm để lấy lại các tệp riêng lẻ, mặc dù tôi có thể lưu hình ảnh của đĩa không được mã hóa trước khi tôi xây dựng lại, chỉ trong trường hợp.

smartctlkhông hiển thị bất kỳ lỗi nào, bản ghi kernel cũng không. Chạy chế độ ghi badblockstrên trao đổi lv cũng không tìm thấy vấn đề. Vì vậy, đĩa có thể bị lỗi, nhưng không phải là một cách rõ ràng.

Tại thời điểm này, về cơ bản, như họ nói, fscked? Quay lại cài đặt lại, có lẽ đang chạy badblocks trên đĩa, sau đó khôi phục lại từ bản sao lưu? Thậm chí dường như không có đủ dữ liệu để gửi một lỗi có ý nghĩa ...

Tôi không nhớ rằng máy này đã bị hỏng lần trước khi tôi sử dụng nó.

Tại thời điểm này, tôi nghi ngờ có lỗi hoặc hỏng bộ nhớ khiến nó ghi rác trên các đĩa khi nó chạy lần cuối hoặc một loại chế độ lỗi tinh vi nào đó cho SSD.

Bạn nghĩ gì sẽ gây ra điều này? Có điều gì khác bạn muốn thử không?

Có vẻ như siêu khối đầu tiên của bạn bị hỏng. Có nhiều bản sao của siêu khối, vì nó là phần quan trọng nhất của hệ thống tập tin. Bạn có thể thử e2fsckvới -btùy chọn để kiểm tra xem một bản sao khác của siêu khối có thông tin chính xác hay không. Kiểm tra e2fsck (8) để biết thêm thông tin về -btùy chọn và cách xác định vị trí của các siêu khóa bổ sung.

IIRC, chỉ có một bản sao của thư mục gốc, vì vậy nếu nó bị hỏng, nó sẽ phải được tạo lại, trống rỗng. Các thư mục ban đầu trong thư mục gốc sẽ xuất hiện trong / mất + tìm thấy và bạn sẽ phải di chuyển chúng từ đó.

Bảng inode được trải qua phân vùng. Không chắc là bạn sẽ mất tất cả chúng. Những tệp có thể phục hồi được, nếu các tệp của chúng không thể được chuyển đến thư mục gốc, chúng cũng sẽ kết thúc bằng / mất + tìm thấy.

Tôi đã thấy điều này trước đây. Đó là một cái gì đó để làm với Ubuntu 10.10. Tôi sẽ nhìn xung quanh trình theo dõi lỗi vì nó đã được đăng một vài lần. Để chắc chắn, hãy chụp ảnh đĩa, lau sạch rồi thả nó vào hệ thống thứ cấp để xem lỗi có lặp lại không (để loại trừ đĩa - thủ phạm không có khả năng).

Cập nhật: Cuối cùng, tôi đã bị thuyết phục rằng vấn đề là do một số lỗi SSD phức tạp hoặc tôi cho rằng có thể có sự tương tác giữa kernel và SSD. Tôi đã thay thế nó bằng một đĩa từ tính và tôi không gặp rắc rối nữa.