Cấu hình an toàn của exti cho các hệ thống chạy không giám sát


18

Tôi có một hệ thống chạy linux phải chạy không giám sát trong thời gian dài. Hệ thống sử dụng thẻ CF công nghiệp để lưu trữ. Hầu hết thời gian không có ghi vào flash, mặc dù thỉnh thoảng một số dữ liệu / cài đặt cấu hình có thể được sửa đổi. Hệ thống phải chịu được sự cố mất điện.

Tôi muốn sử dụng ext4 cho việc này. Cách tốt nhất để cấu hình ext4 cho loại thiết lập này là gì? Ghi nhớ rằng:

  • Hiệu suất hoàn toàn không phải là vấn đề (đặc biệt là hiệu suất ghi)
  • Khi mất điện, hệ thống phải luôn khởi động ở trạng thái sạch, ngay cả khi điều đó có nghĩa là dữ liệu được ghi trong vài giây qua bị mất
  • Nếu có thể tránh fsck, thì tốt hơn hết.

(Tôi biết câu hỏi liên quan này: Ngăn chặn hỏng dữ liệu trên ổ đĩa ext4 / Linux khi mất điện )

Câu trả lời:


11

Tôi đã làm việc trong việc xây dựng một hệ thống tự động hóa trên thuyền và có một điều kiện tiên quyết: trong mọi khoảnh khắc, sức mạnh có thể giảm và mọi thứ phải tăng cường trở lại một cách chính xác.

Giải pháp của tôi là xây dựng một hệ thống initramfs dựa trên Gentoo, chỉ có một thư mục rw cho ứng dụng và cấu hình (đây là cách tiếp cận được sử dụng bởi mọi nhà cung cấp bộ định tuyến / tường lửa). Giải pháp này thêm một lớp phức tạp bổ sung khi xử lý nâng cấp hệ thống, nhưng đảm bảo với bạn rằng hệ thống sẽ LUÔN khởi động.

Về câu hỏi cụ thể của bạn, bạn nên bật nhật ký EXT4 để có fsck nhanh hơn (trong vài giây), sử dụng tùy chọn dữ liệu = nhật ký gắn kết, hạ thấp tùy chọn cam kết hoặc sử dụng tùy chọn đồng bộ hóa để luôn luôn trống.

Tham chiếu: http://www.kernel.org/doc/Documentation/filesystems/ext4.txt


Tốt Nếu ứng dụng không ghi quá nhiều dữ liệu, bạn nên hài lòng với tùy chọn đồng bộ hóa.
Giovanni Toraldo

1
Nơi tốt hơn để xem là tài liệu nhân Linux: kernel.org/doc/Documentation/filesystems/ext4.txt Kích hoạt dữ liệu = tạp chí và commit = nrsec để giảm thiểu bất kỳ mất dữ liệu tiềm năng nào (* == mặc định)
Giovanni Toraldo

Các cam kết được tính thời gian chắc chắn rất hữu ích - Tôi tin rằng bạn chỉ có thể giảm xuống còn 1 giây (mặc dù có hình phạt hiệu suất CHÍNH đối với các op chuyên sâu viết), nhưng nếu bạn không đủ khả năng mất 1 giây thì bạn sẽ gặp vấn đề lớn hơn;)
voretaq7

2
một trong những tác động tích cực của việc ghi nhật ký là việc phục hồi sau sự cố là vấn đề phát lại những thay đổi không được cam kết mới nhất, điều này thực sự nhanh hơn việc kiểm tra toàn bộ âm lượng cho sự không nhất quán. Nếu đây là vấn đề chính của bạn, thì bạn nên đi với EXT4 mặc định và hài lòng.
Giovanni Toraldo

1
@Grodriguez "mất" dữ liệu có thể là bất cứ thứ gì từ "Tệp không còn ở đó nữa" đến "Tại sao lại có một đoạn nhân trong cơ sở dữ liệu của tôi?" - Tất cả phụ thuộc vào những gì "mất" :)
voretaq7

12

Tôi sẽ mở đầu điều này bằng cách nói rằng theo như tôi quan tâm, EXT (trong tất cả các phiên bản của nó) là một hệ thống tệp khá khủng khiếp - tôi đã thấy nhiều trường hợp " thú vị " hơn về tham nhũng hệ thống tệp trong số lượng tương đối nhỏ của Linux / EXT {2,3,4} hệ thống tôi đã quản lý hơn số lượng hệ thống tệp Không phải EXT tương đối lớn mà tôi có dịp sử dụng.
Nếu có thể hãy cố gắng chọn một hệ thống tập tin mạnh mẽ hơn. Bạn sẽ cảm ơn chính mình khi điều không thể tránh khỏi xảy ra.


Điều đó đang được nói và tất cả những thành kiến ​​cá nhân của tôi bị bỏ ngỏ và bị gạt sang một bên, EXT4 có ba tính năng mà tôi có thể nghĩ ra có thể giúp bạn giải quyết:

  • Nhật ký
    EXT4 có thể là một hệ thống tập tin Nhật ký, nếu bạn muốn nó được. Bật tính năng ghi nhật ký (và đặc biệt đặt chế độ ghi nhật ký dữ liệu thành journalthông qua tune2fshoặc dưới dạng tùy chọn gắn kết).
    Điều này phát sinh một cú đánh hiệu suất vì tất cả dữ liệu phải được ghi vào tạp chí EXT trước khi nó được "cam kết" với hệ thống tập tin (mỗi lần ghi cơ bản xảy ra hai lần) nhưng nó đảm bảo bạn luôn có thể khôi phục cho đến khi một bản phát lại tạp chí sẽ giúp bạn mà không cần bất kỳ các vấn đề.

  • SYNCMount hronous
    Khi an toàn là tối quan trọng gắn một hệ thống tập tin với synctùy chọn luôn luôn là một ý tưởng tốt. Điều này buộc tất cả ghi vào đĩa ngay lập tức - một lần nữa đây là một cú đánh hiệu suất, nhưng một ý tưởng tốt nếu bạn mong đợi sự cố mất điện hoặc người lạ ngẫu nhiên rút thẻ CF ra.

  • Hạn chế các hệ thống tập tin có thể ghi càng nhiều càng tốt Cái này không cụ thể là EXT, nhưng triết lý Linux quá phổ biến là "chỉ tạo một phân vùng gốc lớn và đổ mọi thứ vào đó", thật ra là ngu ngốc . Tạo một cấu trúc hệ thống tập tin thích hợp ( /, /var, /usr, /home, vv ...), và gắn kết như rất nhiều các hệ thống tập tin chỉ đọc càng tốt.
    Đây từng là lời khuyên phổ biến cho các hệ thống unix vì mục đích bảo mật, nhưng trong trường hợp của bạn, nó có một lợi ích bổ sung: Bạn không thể làm hỏng hệ thống tập tin nếu bạn không thể ghi vào nó.


Chức năng của các mount hoàn toàn đồng bộ không tương đương với việc gọi đơn giản syncsau mỗi lần ghi - Các mount được đồng bộ sẽ không (hoặc ít nhất là không) trả về từ một cuộc gọi ghi hệ thống tập tin cho đến khi dữ liệu nằm trên đĩa. Việc gọi syncsẽ xóa tất cả các ghi đang chờ xử lý, nhưng vẫn còn một cửa sổ (tuy ngắn) giữa khi ghi lại và cuộc gọi của bạn để synctrả về trong khi dữ liệu có thể chưa được ghi vào đĩa.
voretaq7

Bạn đề nghị hệ thống tập tin nào? Bạn có thể định lượng kinh nghiệm của bạn?
Đánh dấu Wagner

@embobo Kinh nghiệm của tôi hoàn toàn là giai thoại: Tôi chưa bao giờ kiểm tra căng thẳng hệ thống tập tin EXT, nhưng một sự cố xuất hiện trong tâm trí tôi là khi tôi có một máy chủ Squid bị "tất cả các nút của tôi đi đâu?!?" - hệ thống tập tin đã bị dậm chân, và bằng cách nào đó sau đó được đánh dấu sạch, nhưng mọi nút đều bằng cách nào đó được để lại trong trạng thái được xác nhận nhưng không bao giờ được tham chiếu. Các fsck để khắc phục tình trạng lộn xộn cụ thể đó là tích cực EPIC (chúng tôi chỉ cần tạo ra một FS mới). Đó là ngày tôi mất hết niềm tin vào gia đình hệ thống tập tin EXT.
voretaq7

Re: Nhật ký, ba tùy chọn là data=journal(những gì tôi đã mô tả ở trên), data=ordered(siêu dữ liệu được ghi lại. Dữ liệu được cam kết vào đĩa trước khi siêu dữ liệu được cam kết với hệ thống tệp) và data=writeback(thực tế là không ghi nhật ký / bảo vệ dữ liệu - Những điều xấu có thể xảy ra sau một sự cố, như rác ở giữa các tập tin). Tôi tin orderedlà mặc định trên hầu hết các bản phân phối Linux hiện nay ...
voretaq7

2
Ngoài "Hạn chế các hệ thống tập tin có thể ghi càng nhiều càng tốt": Trong wiki debian là một hướng dẫn để thực hiện chính xác điều này với nhiều ví dụ về trình nền cần được xử lý đặc biệt. Nó cũng hợp lệ cho hầu hết các distris khác: wiki.debian.org/ReadonlyRoot
krissi

7

EXT4 không có vẻ là sự lựa chọn tốt nhất cho hệ thống của bạn; Tôi sẽ đề nghị xem xét một hệ thống tập tin cấu trúc log. Chúng hoạt động bằng cách xử lý dữ liệu như một luồng cập nhật ghi liên tục vào luồng ảo, với một con trỏ trỏ 'đầu' mới nhất. Cập nhật xảy ra bằng cách ghi dữ liệu và siêu dữ liệu vào bộ lưu trữ, sau đó cập nhật con trỏ. Trong trường hợp có sự cố sau khi ghi nhưng trước khi con trỏ cập nhật, dữ liệu mới nhất sẽ bị mất nhưng hệ thống tệp là nhất quán.

Hai hệ thống tập tin ứng cử viên là LogFSNILFS . Cả hai đều có sẵn trong nhân Linux chính.


1

Tôi tò mò về thiết bị tòa nhà của bạn. Bạn đang theo độ tin cậy của một thiết bị nhúng trong khi sử dụng một hệ thống tập tin không thực sự phù hợp.

Ext4 (và gia đình) là một hệ thống tập tin có mục đích chung tốt với (tôi đoán) nhiều tỷ giờ sử dụng trên các trường hợp phần cứng và sử dụng khác nhau. Tuy nhiên, những gì bạn yêu cầu không thực sự phù hợp với ext4. Các con trỏ từ voretaq7 và Giovanni sẽ giúp tận dụng tốt nhất việc sử dụng ext4 nếu bạn phải, nhưng câu trả lời thực sự là sử dụng thứ gì đó phù hợp hơn với yêu cầu của bạn. Steve đã cho bạn một vài lựa chọn. Nếu bạn tiếp tục kéo sức mạnh từ một ext4 FS, cuối cùng bạn sẽ gặp rắc rối.

Nếu đây là một hệ thống tắt mà bạn đang xây dựng, bạn nên lựa chọn sử dụng thứ gì đó phù hợp hơn hoặc chấp nhận rằng sẽ có vấn đề tại một số điểm. Nó chỉ có thể là 1 lần mất điện trong số 100 hoặc 1 trên 1000. Điều đó có thể đủ tốt để bạn chấp nhận rủi ro và thiết bị có thể chạy trong một thời gian dài (nhiều năm) mà không cần bất kỳ sự can thiệp thủ công nào.

Nếu đây là một sản phẩm mà bạn dự định triển khai / đưa ra thị trường rộng rãi, bạn có quyền lựa chọn sử dụng một cái gì đó phù hợp hơn. Hoặc bạn đưa ra quyết định kinh doanh để hỗ trợ một tỷ lệ phần trăm của các thiết bị sẽ bị gạch mỗi năm và cần thay thế hoặc can thiệp thủ công để khôi phục chúng.

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.