Tại sao bạn không thể fsck một phân vùng gắn kết?


43

Nó nổi tiếng rằng bạn không bao giờ nên fsck một phân vùng được gắn kết. Tôi có thể hiểu làm thế nào điều này có thể dễ dàng dẫn đến tham nhũng nếu hệ thống tập tin được ghi bởi fsck (ví dụ: tùy chọn -a được sử dụng), nhưng tại sao các kiểm tra chỉ đọc không thể chạy trên các đĩa được gắn?

Câu trả lời:


28

Từ:

http://linux.die.net/man/8/fsck.ext3

"Lưu ý rằng nói chung nó không phải là an toàn để chạy e2fscktrên hệ thống tập tin được gắn kết. Trường hợp ngoại lệ duy nhất là khi -nlựa chọn được chỉ định, và -c, -lhoặc -Ltùy chọn không được chỉ định. Tuy nhiên, ngay cả khi nó là an toàn để làm như vậy, kết quả in bằng e2fscklà không hợp lệ nếu hệ thống tập tin được gắn kết. Nếu e2fsckhỏi bạn có nên kiểm tra hệ thống tập tin được gắn kết hay không, câu trả lời đúng duy nhất là '' không ''. Chỉ những chuyên gia thực sự biết họ đang làm gì mới nên xem xét trả lời câu hỏi này. đường. "


3
Một ngoại lệ: nếu hệ thống tập tin được gắn ở chế độ chỉ đọc và fsck cũng ở chế độ chỉ đọc, thì mọi thứ đều ổn
Demi

31

Vấn đề cơ bản là trình kiểm tra hệ thống tệp (thường) không phải là một phần của hệ thống tệp. Thay vào đó, nó là một chương trình riêng biệt đọc và ghi vào cùng một đĩa với mã hệ thống tệp trong kernel. Kết quả là, nếu bạn chạy fsck trên một hệ thống tệp đang hoạt động, bạn có hai thực thể khác nhau đang đọc (và có khả năng sửa đổi) cùng một dữ liệu (đĩa), nhưng chúng không phối hợp với nhau theo bất kỳ cách nào. Kết quả, như những người khác đã chỉ ra, là hầu hết người kiểm tra mong đợi rằng không ai khác đang thay đổi siêu dữ liệu hệ thống tệp trong khi họ chạy. Họ sẽ bị lẫn lộn và / hoặc báo cáo lỗi giả nếu hệ thống tệp kernel thay đổi một cái gì đó mà trình kiểm tra không mong đợi.

Có một vài hệ thống tệp có trình kiểm tra được thiết kế rõ ràng để chạy "trực tuyến" (nghĩa là trong khi hệ thống tệp đang hoạt động). Các phiên bản mới hơn của FFS / UFS thực hiện điều này bằng cách chạy fsck dựa trên ảnh chụp nhanh gần đây của hệ thống tệp (bản sao chỉ đọc, tại thời điểm, sao chép khi ghi). Nếu nó tìm thấy các vấn đề, chẳng hạn như sự không nhất quán trong bản đồ bit phân bổ, nó sẽ sửa chúng thông qua cuộc gọi hệ thống, thay vì ghi vào đĩa thô. Điều này cho phép nó phối hợp với hệ thống tập tin hoạt động.

WAFL của NetApp cũng có một công cụ kiểm tra trực tuyến. Có lẽ có những người khác.


11

Chạy fsck trên một phân vùng gắn đọc-ghi sẽ là ngớ ngẩn, ngay cả với fsck ở chế độ chỉ đọc. Hệ thống tập tin sẽ thay đổi theo fsck và dữ liệu trong bộ nhớ mà fsck lưu trữ từ hệ thống tập tin sẽ trở nên không hợp lệ (và do đó fsck sẽ thấy sự không nhất quán). Bạn có thể chạy fsck trên hệ thống tệp được gắn chỉ đọc ở chế độ chỉ đọc và nhận kết quả hợp lệ. Chạy fsck ở chế độ đọc / ghi trên hệ thống tệp được gắn chỉ đọc, nếu fsck thay đổi hệ thống tệp trong quá trình chạy, sẽ khiến kernel thấy cấu trúc hệ thống tệp thay đổi bất ngờ bên dưới nó. Điều đó cũng sẽ là xấu.


Bạn đã viết "Chạy fsck ở chế độ đọc / ghi trên hệ thống tệp được gắn chỉ đọc sẽ khiến kernel thấy cấu trúc hệ thống tệp thay đổi bất ngờ bên dưới nó". Tại sao cấu trúc hệ thống tập tin thay đổi trên hệ thống tập tin gắn kết chỉ đọc?
guettli

Theo câu trả lời này, fsck trên phân vùng chỉ đọc là ok, nếu bạn khởi động lại sau phường: serverfault.com/a/405252/90324
guettli 16/11/18

@guettli - Câu trả lời bạn liên kết đến là nói nhiều điều tương tự như tôi. (Tôi đã sửa lỗi chính tả của mình, BTW. Cảm ơn!) Nếu fsck thực hiện thay đổi trong khi kernel có hệ thống tệp được gắn dữ liệu được lưu trong bộ nhớ cache chỉ đọc bên trong kernel có thể trở nên không hợp lệ do các thay đổi do fsck thực hiện. Chắc chắn, bạn có thể khởi động lại sau đó. Bạn cũng có thể phát hiện ra một lỗi kernel thú vị và hoảng loạn kernel của bạn trước khi bạn có cơ hội khởi động lại.
Evan Anderson

9

Ngoài thực tế là nó có thể sẽ giết chết thông lượng I / O của bạn, nếu hệ thống tập tin đang được sửa đổi trong khi nó là fsck thì không có cách nào fsck có thể theo dõi các thay đổi và báo cáo các sự cố.

Một số hệ thống tệp như XFS cho phép bạn thực hiện kiểm tra tính nhất quán trong khi hệ thống tệp được gắn đọc-ghi, với cảnh báo rằng các lỗi giả sẽ có thể được báo cáo. xfs_checkkhuyến nghị hệ thống tập tin không được ngắt hoặc gắn chỉ đọc trước khi thực hiện kiểm tra.


6

Vâng, quan điểm của fsck là báo cáo sự không nhất quán của hệ thống tập tin, đó là vi phạm bất biến.

Tuy nhiên, nhiều trong số các kiểm tra này liên quan đến nhiều hơn một cấu trúc FS. Nếu ai đó đang sửa đổi FS (ghi dữ liệu), các cấu trúc này có thể tạm thời không đồng bộ. fsck sẽ xem đây là một sự không nhất quán, mặc dù nó không thực sự là một vấn đề. fsck không có cách nào để biết liệu sự không nhất quán chỉ là tạm thời hay là sự cố vĩnh viễn cần khắc phục. Vì vậy, điều này không thể thực hiện được (Trừ khi một FS được thiết kế đặc biệt để cho phép kiểm tra trực tuyến. Một số thì có, nhưng ext3 thì không).


3

Bạn có thể. fsck -n / dev / sda1 sẽ làm chính xác điều đó, ít nhất là trên ext3. Tôi vừa mới thử nó :)


-4

Bạn có thể, giống như bạn có thể dính tay vào máy xay sinh tố đang di chuyển và có thể không tự làm mình bị thương, hoặc giống như bạn có thể nhảy từ một tòa nhà cao tầng trong khi nhắm vào đống đệm nhỏ bạn đặt trên vỉa hè bên dưới.

Nhưng tại sao bạn, ngoài việc kiểm tra tỷ lệ tử vong của chính bạn? Bởi vì ông chủ của bạn chắc chắn sẽ kiểm tra lại khi anh ta phát hiện ra TẠI SAO máy chủ thư sẽ không nhận ra ổ đĩa gốc bây giờ.


Trên thực tế, tôi nghĩ rằng một sự tương tự tốt hơn sẽ là nhìn vào một máy xay đang di chuyển, hoặc liếc qua rìa của một tòa nhà cao tầng. Chỉ đọc.
mike
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.