Để fsck hoặc không fsck sau 180 ngày

Theo mặc định sau 180 ngày hoặc một số lần gắn kết, hầu hết các hệ thống tệp Linux buộc phải kiểm tra hệ thống tệp (fsck). Tất nhiên điều này có thể được tắt bằng cách sử dụng, ví dụ, Tune2fs -c 0 -i 0 trên ext2 hoặc ext3.

Trên các hệ thống tập tin nhỏ, kiểm tra này chỉ là một sự bất tiện. Tuy nhiên, với các hệ thống tập tin lớn hơn, kiểm tra này có thể mất hàng giờ để hoàn thành. Khi người dùng của bạn phụ thuộc vào hệ thống tệp này cho năng suất của họ, giả sử nó đang phục vụ các thư mục chính của họ thông qua NFS, bạn có vô hiệu hóa kiểm tra hệ thống tệp theo lịch trình không?

Tôi hỏi câu hỏi này vì hiện tại là 2:15 sáng và tôi đang chờ một fsck rất dài để hoàn thành (ext3)!

Thời gian fsck mặc định 180 ngày là một giải pháp cho lỗ hổng thiết kế mà ext3 không hỗ trợ kiểm tra tính nhất quán trực tuyến. Giải pháp thực sự là tìm một hệ thống tập tin hỗ trợ này. Tôi không biết nếu có bất kỳ hệ thống tập tin trưởng thành nào. Đó là một bi kịch thực sự. Có lẽ btrfs sẽ cứu chúng ta một ngày.

Tôi đã trả lời vấn đề thời gian ngừng hoạt động nhiều giờ bất ngờ từ fsck bằng cách thực hiện khởi động lại theo lịch trình với một fsck đầy đủ như một phần của bảo trì tiêu chuẩn. Điều này tốt hơn là chạy vào tham nhũng nhỏ trong giờ sản xuất, và biến nó thành một cúp điện thực sự.

Một phần lớn của vấn đề là ext3 có fsck chậm một cách vô lý. Mặc dù xfs có fsck nhanh hơn nhiều, nhưng nó sử dụng quá nhiều bộ nhớ cho các bản phân phối để khuyến khích xfs theo mặc định trên các hệ thống tệp lớn. Tuy nhiên, trên hầu hết các hệ thống, đây không phải là vấn đề. Chuyển sang xfs ít nhất sẽ cho phép một fsck hợp lý nhanh. Điều này có thể làm cho việc chạy fsck như một phần của bảo trì bình thường dễ dàng hơn để lên lịch.

Nếu bạn đang chạy RedHat và xem xét sử dụng xfs, bạn phải cẩn thận về việc họ không khuyến khích việc sử dụng xfs mạnh đến mức nào và thực tế là có rất ít người sử dụng xfs trên kernel bạn đang chạy.

Hiểu biết của tôi là dự án ext4 có mục tiêu ít nhất là phần nào cải thiện hiệu suất fsck.

Tôi muốn nói rằng đây chỉ là một lý do khác mà các máy chủ sản xuất không nên chạy một mình và luôn có một bản sao lưu nóng / lạnh hoặc tham gia vào một cụm hai nút. Trong những ngày ảo hóa này, bạn có thể dễ dàng có một máy chủ chính vật lý và máy chủ ảo, đây chỉ là một bản sao của vật lý được thực hiện mỗi X ngày, sẵn sàng để tiếp quản.

Khác thì đây không phải là câu trả lời hữu ích, tôi sẽ nói rằng bạn nên cân bằng tầm quan trọng của dữ liệu của mình ... Nếu đây chỉ là một nút cụm, hãy bỏ qua nó. Nếu đây là máy chủ web không được sao lưu của khách hàng, bạn có thể muốn lập kế hoạch trước vào lần tới :-)

Phụ thuộc .. Ví dụ, chúng tôi đã có một máy chủ ngừng hoạt động để bảo trì định kỳ đang chạy một ngăn xếp QMail. QMail tạo và giết rất nhiều tệp khi thời gian trôi qua và đó là một máy chủ thư rất bận rộn. Các fsck mất khoảng 36 giờ. Nó không giống như chúng tôi đã tiết kiệm rất nhiều hiệu suất trong thỏa thuận, nhưng cuối cùng tôi cho rằng bạn có thể tranh luận rằng hệ thống tập tin lành mạnh hơn. Có thực sự đáng giá sự hỗn loạn xảy ra sau đó? Không phải. Tại. Tất cả các.

XFS thật thú vị. Đó là một FS luôn luôn nhất quán. Nó không cần fsck. Nó sẽ không gây ra thời gian chết do fsck.

Nhưng nó có một vấn đề khác. Bạn cần một bộ điều khiển RAID có hỗ trợ xử lý các khối xấu của HDD.

XFS không có tính năng liệt kê các khối xấu khi hệ điều hành bắt đầu biết về các khối xấu và danh sách các khối xấu của phần cứng HDD đã đầy.

ext2 / 3/4, fat, ntfs, v.v (kiểm tra ngoại tuyến) có thể đưa vào danh sách đen các khối xấu nhưng không phải XFS.

Vì vậy, đối với các bản cài đặt không dành cho doanh nghiệp, XFS có thể không phù hợp lắm. Tôi đang sử dụng XFS với phần mềm linux raid1 cho các phân vùng sao lưu trong đó nội dung có rất nhiều tệp nhỏ không có nhiều thay đổi theo thời gian.