Khi nào fsck nguy hiểm?

37

Gần đây tôi đã thấy hệ thống tập tin gốc của một máy trong trung tâm dữ liệu từ xa được xem lại chỉ đọc, do các vấn đề về tính nhất quán.

Khi khởi động lại, lỗi này đã được hiển thị:

UNEXPECTED INCONSISTENCY: RUN fsck MANUALLY (i.e., without -a or -p options)

Sau khi chạy fsck như đề xuất và chấp nhận sửa lỗi bằng tay Y, các lỗi đã được sửa và hệ thống hiện đã ổn.

Bây giờ, tôi nghĩ rằng sẽ rất thú vị nếu fsck được cấu hình để chạy và sửa chữa mọi thứ tự động, vì sự thay thế duy nhất trong một số trường hợp (như thế này) sẽ trực tiếp đến trung tâm dữ liệu từ xa và gắn bàn điều khiển vào máy bị ảnh hưởng.

Câu hỏi của tôi là: tại sao fsck theo mặc định yêu cầu can thiệp thủ công? Làm thế nào và khi nào một sự điều chỉnh được thực hiện bởi chương trình như vậy sẽ không an toàn? Đó là những trường hợp khi sysadmin có thể muốn để một sự điều chỉnh được đề xuất sang một bên trong một thời gian (để thực hiện một số thao tác khác) hoặc hủy bỏ hoàn toàn?

— scristalli
nguồn

15

Nếu các nhà phát triển tự tin 100%, lỗi có thể được sửa tự động, thì đó sẽ không phải là lỗi ngay từ đầu.

— dùng253751

42

fsckchắc chắn gây ra nhiều tác hại hơn là tốt nếu phần cứng bên dưới bị hư hỏng; CPU xấu, RAM xấu, ổ cứng sắp chết, bộ điều khiển đĩa bị hỏng ... trong những trường hợp đó, tham nhũng nhiều hơn là không thể tránh khỏi.

Nếu nghi ngờ, bạn chỉ nên chụp ảnh đĩa bị hỏng bằng dd_rescuehoặc một số công cụ khác, sau đó xem liệu bạn có thể sửa thành công hình ảnh đó không. Bằng cách đó bạn vẫn có sẵn thiết lập ban đầu.

— Janne Pikkarainen
nguồn

4

Tôi đã làm việc rất nhiều với lỗi phần cứng và tôi đồng ý với điều này. Điều cuối cùng tôi muốn làm là fsck nếu có bất kỳ loại phần cứng xấu nào. Tôi cũng đã thấy một sự kiện năng lượng thấp và phục hồi sau đó đã bị trì hoãn rất nhiều bởi fsck tự động.

— jorfus

Để đưa ra một ví dụ cụ thể: Tôi đã làm việc trên một máy có bộ điều khiển đĩa "ngẫu nhiên" (khoảng 1 lần trong 10 ^ 5) sẽ chuyển việc đọc hoặc ghi để chặn XXXXXXYY trên bất kỳ thiết bị nào thành ghi để chặn 000000YY trên thiết bị đầu tiên. Tức là, nó thường xuyên phá hủy cấu trúc dữ liệu sai và không cấu trúc cho khu vực khởi động và các cấu trúc hệ thống tập tin quan trọng khác nhau của đĩa khởi động. Chạy fsck trong tình huống như vậy (hàng triệu lượt đọc) có thể loại bỏ mọi cơ hội khôi phục dữ liệu còn lại.

— Tháp Eric

2

1 trong 10 ^ 5 là rất nhiều ... đó là 10 byte từng Mb.

— Nelson

1

@Nelson: Nó là ... Đơn vị có "chuyển khối đơn", không phải "byte". Vì vậy, mười khối xấu ghi trên một triệu khối (và các khối lớn hơn đáng kể so với byte).

— Tháp Eric

21

Bạn đã thấy một ví dụ nơi fsckhoạt động, nhưng tôi đã thấy nhiều hơn các hệ thống tệp bị hỏng đủ để nó không hoạt động thành công. Nếu nó hoạt động hoàn toàn tự động, bạn có thể không có cơ hội làm những việc như ddđổ đĩa hoặc những thứ tương tự mà trong nhiều trường hợp sẽ là một ý tưởng tuyệt vời để làm trước khi thử sửa chữa.

Không bao giờ, bao giờ là một ý tưởng tốt để thử một cái gì đó như thế tự động cả.

Ồ, và các máy chủ hiện đại nên có bảng điều khiển từ xa hoặc ít nhất là các hệ thống cứu hộ độc lập để phục hồi từ một thứ tương tự mà không cần gắn giá đỡ KVM vào máy chủ.

— Sven
nguồn

7

Trên thực tế, những gì không phải là một ý tưởng tốt là nói " không bao giờ, bao giờ " như thế, khi nó không đúng. Trường hợp sử dụng trong trường hợp đó là một ý tưởng tốt: Các phân vùng chính của máy chủ có thể được tạo lại từ đầu khá nhanh, trong trường hợp có vấn đề. Thực tế dữ liệu quan trọng được truy cập thông qua một hệ thống tập tin từ xa, với sự dự phòng thích hợp cho dữ liệu đó. Tôi thà nắm lấy cơ hội fsck -p /và fsck -p /var, v.v., làm việc tốt, và mở máy chủ mà không cần can thiệp thủ công, và có nguy cơ thảm họa lớn, không bằng 0% cho những phân vùng mà tôi có thể tạo lại nếu cần .

— TUYỆT VỜI

1

Nếu hệ thống có thể dễ dàng cài đặt lại, tôi chỉ cần làm điều đó ...

— Sven

1

Điều đó sẽ mất nhiều thời gian hơn. Các tùy chọn là: A) Rủi ro khi thực hiện nó tự động. B) Có ai đó nói fsckvới preen, và sau đó mọi thứ hoạt động tốt. Mất khoảng 2 phút, nếu vậy. Thời gian chết cho đến khi điều này xảy ra. C) Có người cài đặt lại hệ điều hành. Mất hơn 30 phút. Bạn đang chọn tùy chọn C? Có lẽ một điểm khác biệt chính mà chúng tôi có là tôi đã fscklàm việc với tỷ lệ phần trăm thời gian lớn hơn so với những gì bạn trích dẫn trong câu trả lời của mình. Quan điểm chính của tôi không phải là thiết kế hệ thống (hệ thống giá rẻ này không sử dụng bảng điều khiển từ xa), nhưng chỉ cần nói rằng " không bao giờ, bao giờ " là một cụm từ quá chính xác

— TUYỆT VỜI

Chúng ta hãy đồng ý không đồng ý.

— Sven

0

Trước hết, bạn cần hiểu rằng với các hệ thống tệp hiện đại (được ghi nhật ký), sự cố hệ thống sẽ không làm hỏng hệ thống tệp và không yêu cầu fsck khi khởi động.

Ext3, Ext4, ZFS, btrfs, xfs và tất cả các FS hiện đại đều nhất quán 100% sau khi gặp sự cố hoặc thiết lập lại hệ thống.

Không được công bố FS như ext2 hoặc vfat là một NOGO lớn cho một rootfs hệ thống.

Bây giờ, nếu hệ thống của bạn yêu cầu fsck khi khởi động, bạn nên tự hỏi: lý do cho việc này ở nơi đầu tiên là gì?

Bạn nên điều tra nhật ký kernel sau đó để tìm hiểu, khi nào và điều gì đã xảy ra. Bạn cũng nên quay ngược thời gian trong nhật ký để tìm từ khi lỗi bắt đầu. Bạn nên kiểm tra đĩa của bạn với smartctl. V.v ... Nếu bạn cần một fsck trên fs đã được công bố, gần như chắc chắn rằng phần cứng của bạn bị lỗi, giả sử fs không bị quản trị viên (với các công cụ cấp khối như dd) hoặc do lỗi.

Vì vậy, thật ngớ ngẩn khi sử dụng fsck để "khắc phục" sự cố mà không điều tra và khắc phục nguyên nhân gốc (bằng cách thay thế / nâng cấp phần cứng / phần mềm / phần mềm bị lỗi).

Làm một fsck, hoàn thành khởi động và hạnh phúc là ngây thơ để nói rằng ít nhất. Nói rằng "Tôi đã có fsck làm việc với tỷ lệ phần trăm thời gian nhiều hơn so với những gì bạn trích dẫn" đang khiến tôi tự hỏi ý của bạn với "công việc fsck". fsck có thể đã đưa fs của bạn trở lại trạng thái nhất quán bằng cách mất một số tệp và dữ liệu trong quy trình ... Bạn đã so sánh với bản sao lưu chưa? Nhiều người mất tập tin hoặc bị hỏng dữ liệu tập tin mà không nhận thấy ...

— Francois Scheurer
nguồn