Hết bộ nhớ đang chạy fsck trên các hệ thống tập tin lớn

Tôi chăm sóc một hộp linux Debian cũ (đang chạy etch) chỉ với 512 MB RAM, nhưng có rất nhiều bộ nhớ ngoài kèm theo. Một hệ thống tập tin ext3 có kích thước 2,7 TB và fsck không thể kiểm tra nó, vì nó hết bộ nhớ, với một lỗi như thế này:

   Lỗi phân bổ mảng khối thư mục: Phân bổ bộ nhớ không thành công
   e2fsck: đã hủy bỏ

Tôi đã thêm phân vùng trao đổi 4 GB và nó vẫn chưa hoàn tất, nhưng đây là kernel 32 bit, vì vậy tôi không mong đợi thêm bất kỳ thứ gì sẽ giúp ích.

Ngoài việc khởi động vào kernel 64 bit, còn có cách nào khác để fsck hoàn thành kiểm tra không?

Một hạt nhân 64 bit và số lượng lớn RAM sẽ cho phép fsck hoàn thành tốt và nhanh chóng. Thay vào đó, giờ đây có một tùy chọn trong e2fsck sẽ bảo nó lưu trữ tất cả các kết quả trung gian của nó trong một thư mục thay vì trong RAM, giúp ích rất nhiều. Tạo /etc/e2fsck.confvới các nội dung sau:

[scratch_files]
directory = /var/cache/e2fsck

(Và, rõ ràng, đảm bảo rằng thư mục đó tồn tại và nằm trên một phân vùng có một vài GB dung lượng trống). e2fsck sẽ chạy SLLOOOOWWWWWWW, nhưng ít nhất nó sẽ hoàn thành.

Tất nhiên, điều này sẽ không hoạt động với FS gốc, nhưng nếu bạn đã trao đổi thì dù sao bạn cũng đã cài đặt FS gốc.

Tôi cuối cùng đã thử những gì womble đề nghị; Dưới đây là một số chi tiết có thể hữu ích nếu như tôi, bạn chưa thấy chức năng mới này trong e2fsck trước đây.

Tùy chọn cấu hình "scratch_files" cho e2fsck đôi khi có sẵn trong phiên bản 1.40.x. (Trong trường hợp của chúng tôi, chúng tôi đã phải nâng cấp lên bản phân phối Debian mới nhất để có được chức năng này.)

Cũng như tùy chọn "thư mục = / var / cache / e2fsk" đã được đề xuất, có một số tùy chọn cấu hình khác để tinh chỉnh cách sử dụng lưu trữ tệp cào. Tôi đã sử dụng "dirinfo = false", vì hệ thống tệp có số lượng tệp lớn, nhưng không phải là số lượng lớn các thư mục. Nếu tình huống đã được đảo ngược, tùy chọn "icount" sẽ phù hợp. Các tùy chọn này đều được ghi lại trong trang man cho e2fsck.conf.

BTW, Ted T'so đã viết về các tùy chọn này trong chủ đề này .

Tôi thấy rằng e2fsck đang chạy rất chậm, nhiều hơn dự đoán của Ted. Nó đã chạy với tốc độ sử dụng CPU 99,9% trong hầu hết thời gian (trên bộ xử lý cũ cực kỳ chậm), điều này cho thấy rằng việc lưu trữ các cấu trúc dữ liệu này trên đĩa thay vì bộ nhớ không phải là nguyên nhân chính gây ra sự chậm chạp. Nó có thể là một cái gì đó khác về những gì được lưu trữ trong hệ thống tập tin làm cho e2fsck đặc biệt chậm. Cuối cùng, tôi đã từ bỏ việc kiểm tra hệ thống tập tin; hệ thống tập tin là do kiểm tra, nhưng không có lỗi (theo như tôi biết), vì vậy tôi sẽ sắp xếp để kiểm tra nó vào thời điểm thuận tiện hơn khi chúng tôi có thể mất điện kéo dài một tuần.