2012-10-20 24 views
7

Tôi đang viết một số phần mềm để xử lý dữ liệu khá quan trọng và cần biết chính xác tôi cần làm gì để đạt được độ bền.Cần gì để có độ bền cao trên Linux?

Ở mọi nơi tôi nhìn là thông tin mâu thuẫn, vì vậy tôi đánh giá cao mọi thông tin chi tiết.

Có ba cách tôi ghi vào đĩa.

  • Sử dụng O_DIRECT | O_DSYNC, và pread'ing và sau đó pwrite'ing 512 byte - khối 16 MB.

  • Sử dụng O_DIRECT, pread'ing và sau đó pwrite'ing khối 512 byte và gọi fdatasync thường xuyên nếu cần.

  • Sử dụng tệp ánh xạ bộ nhớ, mà tôi gọi là msync (..., MS_SYNC | MS_INVALIDATE) cho thường xuyên nếu cần.

Và đây là tất cả trên ext4 có cờ mặc định.

Đối với tất cả những điều này, liệu có thể mất dữ liệu (sau khi ghi hoặc đồng bộ hóa đã trả lại) hoặc bị hỏng do mất điện, hoảng loạn, tai nạn hoặc bất kỳ thứ gì khác không? Có thể là nếu máy chủ của tôi chết giữa pwrite, hoặc giữa đầu pwrite và kết thúc fdatasync, hoặc giữa bộ nhớ được ánh xạ bị thay đổi và msync, tôi sẽ kết hợp dữ liệu cũ và mới, hoặc nó sẽ là một hay khác? Tôi muốn các cuộc gọi pwrite riêng lẻ của tôi trở thành nguyên tử và được yêu cầu. Đây có phải là trường hợp không? Và nó có phải là trường hợp nếu chúng ở trên nhiều tệp không? Vì vậy, nếu tôi viết với O_DIRECT | O_DSYNC đến A, rồi O_DIRECT | O_DSYNC đến B, tôi có đảm bảo rằng, không có vấn đề gì xảy ra, nếu dữ liệu trong B nó cũng trong A?

Liệu fsync có đảm bảo rằng dữ liệu được viết không? This nói không, nhưng tôi không biết nếu mọi thứ đã thay đổi kể từ đó.

Hiện journalling của ext4 có hoàn toàn giải quyết được vấn đề của các khối bị hỏng mà this SO answer nói tồn tại không?

Tôi hiện đang phát triển các tệp bằng cách gọi posix_fallocate và sau đó ftruncate. Cả hai đều cần thiết, và họ có đủ không? Tôi figured rằng ftruncate thực sự sẽ khởi tạo các khối được phân bổ để tránh these issues.

Để thêm nhầm lẫn vào danh sách kết hợp, tôi đang chạy tính năng này trên EC2, tôi không biết điều đó có ảnh hưởng gì không. Mặc dù nó làm cho nó rất khó để kiểm tra như tôi không thể kiểm soát như thế nào tích cực nó bị đóng cửa.

+1

Dữ liệu luôn có thể bị mất, ít nhất là do lỗi phần cứng (hoặc phần mềm). Bạn nên sao lưu (tức là sao chép) nó, hoặc ít nhất là tính toán một số kiểm tra (để có thể xác nhận hoặc vô hiệu hóa nó). Tôi không chắc chắn rằng chơi thủ đoạn syscall là đủ. Tôi sẽ cố gắng để nhân đôi và kiểm tra dữ liệu quan trọng đó, và có lẽ nghĩ về giao dịch. –

+2

@BasileStarynkevitch Ở lớp trên, dữ liệu chỉ được coi là được viết khi hai nút đã xác nhận nó và chúng tôi cũng chụp ảnh nhanh hàng ngày. Chúng tôi xem xét điều này đủ, nó chỉ đảm bảo rằng dữ liệu được * thực sự * ghi vào ổ cứng trước khi xác nhận đó là vấn đề. – Max

Trả lời

3

Đối với tất cả những dữ liệu này, dữ liệu có thể bị mất (sau khi viết hoặc đồng bộ đã trả lại) hoặc bị hỏng do mất điện, hoảng loạn, tai nạn hoặc bất kỳ thứ gì khác?

Tuyệt đối.

Liệu fsync có đảm bảo rằng dữ liệu được ghi không? Điều này nói không, nhưng tôi không biết nếu mọi thứ đã thay đổi kể từ đó.

No. Câu trả lời phụ thuộc vào thiết bị và có khả năng phụ thuộc vào hệ thống tệp. Thật không may, hệ thống tập tin đó có thể là các lớp và lớp trên thiết bị lưu trữ "thực tế". (ví dụ.md, lvm, fuse, loop, ib_srp, v.v ...).

Mặc dù nó rất khó kiểm tra vì tôi không thể kiểm soát mức độ tích cực của nó.

Đó là sự thật. Nhưng bạn có lẽ vẫn có thể sử dụng một NMI hoặc sysrq-trigger để tạo ra một tạm dừng khá đột ngột.

Các vấn đề liên quan