Tôi đã từng nghĩ rằng các thay đổi tệp được lưu trực tiếp vào đĩa, nghĩa là ngay sau khi tôi đóng tệp và quyết định nhấp / chọn lưu. Tuy nhiên, trong một cuộc trò chuyện gần đây, một người bạn của tôi nói với tôi rằng điều đó thường không đúng; HĐH (cụ thể là chúng ta đã nói về các hệ thống Linux) giữ các thay đổi trong bộ nhớ và nó có một trình nền thực sự ghi nội dung từ bộ nhớ vào đĩa.

Ông thậm chí còn đưa ra ví dụ về các ổ đĩa flash ngoài: chúng được gắn vào hệ thống (được sao chép vào bộ nhớ) và đôi khi mất dữ liệu xảy ra do trình nền chưa lưu nội dung vào bộ nhớ flash; đó là lý do tại sao chúng tôi ngắt kết nối ổ đĩa flash.

Tôi không có kiến ​​thức về hoạt động của hệ điều hành, và vì vậy tôi hoàn toàn không biết liệu điều này có đúng không và trong hoàn cảnh nào. Câu hỏi chính của tôi là: điều này có xảy ra như được mô tả trong các hệ thống Linux / Unix (và có thể các hệ điều hành khác) không? Chẳng hạn, điều này có nghĩa là nếu tôi tắt máy tính ngay sau khi tôi chỉnh sửa và lưu một tập tin, những thay đổi của tôi rất có thể sẽ bị mất? Có lẽ nó phụ thuộc vào loại đĩa - ổ cứng truyền thống so với đĩa trạng thái rắn?

Câu hỏi đề cập cụ thể đến các hệ thống tập tin có đĩa để lưu trữ thông tin, mặc dù mọi sự làm rõ hoặc so sánh đều được đón nhận.

Nếu tôi tắt máy tính ngay sau khi tôi chỉnh sửa và lưu tệp, những thay đổi của tôi rất có thể bị mất?

Học có thể bị. Tôi sẽ không nói "rất có thể", nhưng khả năng phụ thuộc vào rất nhiều thứ.

Một cách dễ dàng để tăng hiệu suất ghi tệp, là cho HĐH chỉ lưu trữ dữ liệu, nói (nói dối) ứng dụng mà ghi đã đi qua, và sau đó thực sự ghi lại sau đó. Điều này đặc biệt hữu ích nếu có hoạt động đĩa khác diễn ra cùng một lúc: HĐH có thể ưu tiên đọc và thực hiện ghi sau đó. Nó cũng có thể loại bỏ hoàn toàn nhu cầu ghi thực tế, ví dụ, trong trường hợp một tệp tạm thời bị xóa nhanh chóng sau đó.

Vấn đề bộ nhớ đệm rõ rệt hơn nếu lưu trữ chậm. Sao chép tập tin từ ổ SSD nhanh sang thẻ nhớ USB chậm có thể sẽ liên quan đến rất nhiều bộ nhớ đệm ghi, vì thanh USB không thể theo kịp. Nhưng cplệnh của bạn trả về nhanh hơn, vì vậy bạn có thể tiếp tục làm việc, thậm chí có thể chỉnh sửa các tệp vừa được sao chép.

Tất nhiên bộ nhớ đệm như thế có nhược điểm bạn lưu ý, một số dữ liệu có thể bị mất trước khi nó thực sự được lưu. Người dùng sẽ bị đánh lừa nếu biên tập viên của họ nói với họ rằng việc ghi đã thành công, nhưng tệp không thực sự nằm trên đĩa. Đó là lý do tại sao có fsync()cuộc gọi hệ thống , được cho là chỉ trả về sau khi tệp thực sự chạm vào đĩa. Trình chỉnh sửa của bạn có thể sử dụng điều đó để đảm bảo dữ liệu vẫn ổn trước khi báo cáo cho người dùng rằng việc ghi thành công.

Tôi nói, "đáng lẽ phải thế", vì chính ổ đĩa có thể nói cùng một lời nói dối với HĐH và nói rằng việc ghi đã hoàn tất, trong khi tệp thực sự chỉ tồn tại trong bộ đệm ghi dễ bay hơi trong ổ đĩa. Tùy thuộc vào ổ đĩa, có thể không có cách nào xung quanh đó.

Ngoài ra fsync(), còn có các cuộc gọi sync()và syncfs()hệ thống yêu cầu hệ thống đảm bảo tất cả các ghi trên toàn hệ thống hoặc tất cả ghi trên một hệ thống tệp cụ thể đã chạm vào đĩa. Các tiện ích synccó thể được sử dụng để gọi những người.

Sau đó, cũng có O_DIRECTcờopen() , được cho là "cố gắng giảm thiểu hiệu ứng bộ đệm của I / O đến và từ tệp này." Loại bỏ bộ nhớ đệm làm giảm hiệu suất, do đó, phần lớn được sử dụng bởi các ứng dụng (cơ sở dữ liệu) thực hiện bộ nhớ đệm của riêng họ và muốn kiểm soát nó. ( O_DIRECTkhông phải là không có vấn đề của nó, các ý kiến ​​về nó trong trang man có phần gây cười.)

Điều gì xảy ra khi tắt nguồn cũng phụ thuộc vào hệ thống tập tin. Đó không chỉ là dữ liệu tệp mà bạn nên quan tâm, mà là siêu dữ liệu của hệ thống tệp. Có dữ liệu tệp trên đĩa không được sử dụng nhiều nếu bạn không thể tìm thấy nó. Chỉ cần mở rộng một tệp đến kích thước lớn hơn sẽ yêu cầu phân bổ các khối dữ liệu mới và chúng cần được đánh dấu ở đâu đó.

Cách một hệ thống tập tin xử lý các thay đổi siêu dữ liệu và thứ tự giữa siêu dữ liệu và ghi dữ liệu thay đổi rất nhiều. Ví dụ, với ext4, nếu bạn đặt cờ gắn kết data=journal, thì tất cả ghi - thậm chí ghi dữ liệu - đi qua nhật ký và nên khá an toàn. Điều đó cũng có nghĩa là họ được viết hai lần, do đó hiệu suất giảm. Các tùy chọn mặc định cố gắng ra lệnh ghi để dữ liệu nằm trên đĩa trước khi siêu dữ liệu được cập nhật. Các tùy chọn khác hoặc hệ thống tập tin khác có thể tốt hơn hoặc xấu hơn; Tôi thậm chí sẽ không thử một nghiên cứu toàn diện.

Trong thực tế, trên một hệ thống được tải nhẹ, tệp sẽ chạm vào đĩa trong vòng vài giây. Nếu bạn đang xử lý bộ nhớ di động, hãy ngắt kết nối hệ thống tập tin trước khi kéo phương tiện để đảm bảo dữ liệu thực sự được gửi đến ổ đĩa và không có hoạt động nào nữa. (Hoặc có môi trường GUI của bạn làm điều đó cho bạn.)

Có một cách cực kỳ đơn giản để chứng minh rằng không thể đúng rằng các chỉnh sửa tệp luôn được lưu trực tiếp vào đĩa, đó là thực tế là có các hệ thống tệp không được hỗ trợ bởi đĩa ở vị trí đầu tiên . Nếu một hệ thống tập tin không có một đĩa ở nơi đầu tiên, sau đó nó có thể không có khả năng viết các thay đổi vào đĩa, bao giờ hết .

Một số ví dụ:

• tmpfs, một hệ thống tệp chỉ tồn tại trong RAM (hoặc chính xác hơn là trong bộ đệm bộ đệm)
• ramfs, một hệ thống tệp chỉ tồn tại trong RAM
• bất kỳ hệ thống tệp mạng nào (NFS, CIFS / SMB, AFS, AFP, khắc)
• bất kỳ hệ thống tập tin ảo ( sysfs, procfs, devfs, shmfs, ...)

Nhưng ngay cả đối với các hệ thống tập tin được hỗ trợ bằng đĩa, điều này thường không đúng. Trang Làm thế nào để Tham nhũng Cơ sở dữ liệu SQLite có một chương gọi là Không đồng bộ hóa , mô tả nhiều cách viết khác nhau (trong trường hợp này cam kết với cơ sở dữ liệu SQLite) có thể không đến được trên đĩa. SQLite cũng có một tờ giấy trắng giải thích về nhiều vòng bạn phải nhảy qua để đảm bảo Cam kết nguyên tử trong SQLite . (Lưu ý rằng Viết nguyên tử khó hơn nhiều so với chỉ viết , nhưng tất nhiên ghi vào đĩa là vấn đề phụ của viết nguyên tử và bạn cũng có thể tìm hiểu rất nhiều về vấn đề đó, từ bài báo này.) phần về những điều có thể đi sai bao gồm một phần phụ vềCác đĩa mềm không hoàn chỉnh đưa ra một số ví dụ về những rắc rối tinh vi có thể ngăn việc ghi vào đĩa (chẳng hạn như bộ điều khiển ổ cứng báo cáo rằng nó đã ghi vào đĩa khi thực tế không có - vâng, có những nhà sản xuất ổ cứng làm điều này, và nó thậm chí có thể là hợp pháp theo thông số kỹ thuật ATA, bởi vì nó được nói một cách mơ hồ về mặt này).

Đúng là hầu hết các hệ điều hành, bao gồm Unix, Linux và Windows đều sử dụng bộ đệm ghi để tăng tốc hoạt động. Điều đó có nghĩa là tắt máy tính mà không tắt máy là một ý tưởng tồi và có thể dẫn đến mất dữ liệu. Điều tương tự cũng đúng nếu bạn xóa bộ lưu trữ USB trước khi sẵn sàng để xóa.

Hầu hết các hệ thống cũng cung cấp tùy chọn để thực hiện ghi đồng bộ. Điều đó có nghĩa là dữ liệu sẽ nằm trên đĩa trước khi ứng dụng nhận được xác nhận thành công, với chi phí chậm hơn.

Nói tóm lại, có một lý do tại sao bạn nên tắt máy tính của mình và chuẩn bị bộ lưu trữ USB đúng cách để gỡ bỏ.

1. Lưu trữ dựa trên flash

Có phụ thuộc vào loại đĩa (ổ cứng truyền thống so với đĩa trạng thái rắn) hoặc bất kỳ biến nào khác mà tôi có thể không biết? Có xảy ra (nếu có) chỉ trong Linux hoặc điều này có trong các hệ điều hành khác không?

Khi bạn có lựa chọn, bạn không nên cho phép lưu trữ dựa trên flash bị mất nguồn mà không tắt máy sạch.

Trên bộ lưu trữ chi phí thấp như thẻ SD, bạn có thể mất toàn bộ khối xóa (lớn hơn vài lần so với 4KB), mất dữ liệu có thể thuộc về các tệp khác nhau hoặc cấu trúc thiết yếu của hệ thống tệp.

Một số ổ SSD đắt tiền có thể yêu cầu cung cấp bảo đảm tốt hơn khi đối mặt với sự cố mất điện. Tuy nhiên, thử nghiệm của bên thứ ba cho thấy nhiều ổ SSD đắt tiền không thực hiện được. Lớp ánh xạ lại các khối cho "cân bằng hao mòn" là phức tạp và độc quyền. Thất bại có thể bao gồm mất tất cả dữ liệu trên ổ đĩa.

Áp dụng khung thử nghiệm của chúng tôi, chúng tôi đã kiểm tra 17 ổ SSD hàng hóa từ sáu nhà cung cấp khác nhau sử dụng tổng cộng hơn ba nghìn chu kỳ phun lỗi. Kết quả thử nghiệm của chúng tôi cho thấy 14 trong số 17 thiết bị SSD đã được thử nghiệm thể hiện các hành vi lỗi đáng ngạc nhiên do lỗi nguồn, bao gồm tham nhũng bit, ghi shorn, ghi không thể chỉnh sửa, hỏng siêu dữ liệu và lỗi toàn bộ thiết bị.

2017: https://dl.acm.org/citation.cfm?id=2992782&preflayout=flat

2013: https://www.usenix.org/system/files/conference/fast13/fast13-final80.pdf?wptouch_preview_theme=enables

2. Quay ổ đĩa cứng

Ổ cứng quay có các đặc điểm khác nhau. Để an toàn và đơn giản, tôi khuyên bạn nên giả sử rằng chúng có độ không đảm bảo thực tế giống như lưu trữ dựa trên flash.

Trừ khi bạn có bằng chứng cụ thể, mà bạn rõ ràng là không. Tôi không có số liệu so sánh để quay ổ cứng.

Một ổ cứng có thể để lại một khu vực được viết không hoàn chỉnh với một tổng kiểm tra tồi, điều này sẽ cho chúng ta một lỗi đọc tốt sau này. Nói rộng hơn, chế độ thất bại này của ổ cứng là hoàn toàn mong đợi; hệ thống tập tin Linux nguyên gốc được thiết kế với nó trong tâm trí. Họ nhằm mục đích bảo tồn hợp đồng fsync()khi đối mặt với loại lỗi mất điện này. (Chúng tôi thực sự muốn thấy điều này được đảm bảo trên SSD).

Tuy nhiên tôi không chắc liệu các hệ thống tập tin Linux có đạt được điều này trong mọi trường hợp hay không, thậm chí điều đó có khả thi hay không.

Lần khởi động tiếp theo sau loại lỗi này có thể yêu cầu sửa chữa hệ thống tập tin. Đây là Linux, có thể việc sửa chữa hệ thống tập tin sẽ hỏi một số câu hỏi mà bạn không hiểu, nơi bạn chỉ có thể nhấn Y và hy vọng rằng nó sẽ tự giải quyết.

2.1 Nếu bạn không biết hợp đồng fsync () là gì

Hợp đồng fsync () là nguồn cung cấp cả tin tốt và tin xấu. Bạn phải hiểu tin tốt trước.

Tin tốt: fsync()được ghi chép tốt là cách chính xác để ghi dữ liệu tệp, ví dụ như khi bạn nhấn "lưu". Và người ta hiểu rằng các trình soạn thảo văn bản phải thay thế các tệp hiện có bằng cách sử dụng rename(). Điều này có nghĩa là để đảm bảo rằng bạn luôn giữ tệp cũ hoặc lấy tệp mới (được chỉnh sửa fsync()trước khi đổi tên). Bạn không muốn bị bỏ lại với một phiên bản nửa viết của tệp mới.

Tin xấu: trong nhiều năm, việc gọi fsync () trên hệ thống tệp Linux phổ biến nhất có thể khiến toàn bộ hệ thống bị treo trong hàng chục giây. Vì các ứng dụng không thể làm gì về điều này, nên việc sử dụng đổi tên () mà không có fsync () là rất phổ biến trên hệ thống tập tin này là điều rất phổ biến.

Do đó, các ứng dụng tồn tại không sử dụng fsync () chính xác.

Phiên bản tiếp theo của hệ thống tập tin này thường tránh được lỗi treo fsync () - cùng lúc khi nó bắt đầu dựa vào việc sử dụng đúng fsync ().

Đây là tất cả khá xấu. Hiểu lịch sử này có lẽ không được giúp đỡ bởi giai điệu bác bỏ và lời mời được sử dụng bởi nhiều nhà phát triển nhân xung đột.

Độ phân giải hiện tại là hệ thống tệp Linux phổ biến nhất hiện nay mặc định để hỗ trợ mẫu đổi tên () mà không yêu cầu fsync ()thực hiện "khả năng tương thích bug-for-bug" với phiên bản trước. Điều này có thể được vô hiệu hóa với tùy chọn gắn kết noauto_da_alloc.

Đây không phải là một sự bảo vệ hoàn toàn. Về cơ bản, nó xóa IO đang chờ xử lý tại thời điểm đổi tên (), nhưng nó không đợi IO hoàn thành trước khi đổi tên. Điều này tốt hơn nhiều so với cửa sổ nguy hiểm 60 giây! Xem thêm câu trả lời cho Hệ thống tệp nào yêu cầu fsync () để đảm bảo an toàn khi gặp sự cố khi thay thế tệp hiện có bằng đổi tên ()?

Một số hệ thống tập tin ít phổ biến hơn không cung cấp bảo vệ. XFS từ chối làm như vậy. Và UBIFS cũng không thực hiện nó, rõ ràng nó có thể được chấp nhận nhưng cần rất nhiều công việc để làm cho nó có thể. Cùng một trang chỉ ra rằng UBIFS có một số vấn đề "TODO" khác về tính toàn vẹn dữ liệu, bao gồm cả việc mất điện. UBIFS là một hệ thống tập tin được sử dụng trực tiếp trên bộ lưu trữ flash. Tôi tưởng tượng một số khó khăn mà UBIFS đề cập với bộ lưu trữ flash có thể liên quan đến các lỗi SSD.

Trên một hệ thống được tải nhẹ, kernel sẽ cho phép dữ liệu tệp mới được ghi vào bộ đệm trang trong khoảng 30 giây sau một giây write(), trước khi xóa nó vào đĩa, để tối ưu hóa cho trường hợp nó bị xóa hoặc sửa đổi sớm.

Linux dirty_expire_centisecsmặc định là 3000 (30 giây) và kiểm soát thời gian trước khi dữ liệu mới được viết "hết hạn". (Xem https://lwn.net/Articles/322823/ ).

Xem https://www.kernel.org/doc/Documentation/sysctl/vm.txt để biết thêm các điều chỉnh có liên quan và google để biết thêm. (ví dụ: google trên dirty_writeback_centisecs).

Mặc định của Linux /proc/sys/vm/dirty_writeback_centisecslà 500 (5 giây) và PowerTop khuyên bạn nên đặt nó thành 1500 (15 giây) để giảm mức tiêu thụ điện năng.

Việc ghi lại bị trì hoãn cũng cho thời gian để kernel xem tệp sẽ lớn như thế nào, trước khi bắt đầu ghi nó vào đĩa. Các hệ thống tệp có phân bổ bị trì hoãn (như XFS và có thể là các hệ thống khác hiện nay) thậm chí không chọn vị trí trên đĩa để đặt dữ liệu của tệp mới được ghi cho đến khi cần thiết, tách biệt với không gian cho chính nút inode. Điều này làm giảm sự phân mảnh bằng cách cho phép họ tránh bắt đầu một tệp lớn trong khoảng cách 1 meg giữa các tệp khác, chẳng hạn.

Nếu nhiều dữ liệu đang được ghi, thì việc ghi lại vào đĩa có thể được kích hoạt bởi một ngưỡng cho bao nhiêu dữ liệu bẩn (chưa được đồng bộ hóa với đĩa) có thể có trong pagecache.

Tuy nhiên, nếu bạn không làm gì khác, đèn hoạt động trên ổ cứng của bạn sẽ không sáng trong 5 (hoặc 15) giây sau khi nhấn lưu vào một tệp nhỏ.

Nếu trình soạn thảo của bạn được sử dụng fsync()sau khi ghi tệp, kernel sẽ ghi nó vào đĩa mà không bị trễ. (Và fsyncsẽ không trở lại cho đến khi dữ liệu thực sự được gửi vào đĩa).

Ghi bộ nhớ đệm trong đĩa cũng có thể là một điều, nhưng các đĩa thường cố gắng cam kết bộ đệm ghi của chúng vào bộ nhớ lưu trữ vĩnh viễn, không giống như các thuật toán bộ đệm trang của Linux. Bộ đệm ghi đĩa là một bộ đệm lưu trữ để hấp thụ các đợt ghi nhỏ, nhưng cũng có thể trì hoãn việc ghi có lợi cho việc đọc và cung cấp cho phòng chương trình đĩa để tối ưu hóa mô hình tìm kiếm (ví dụ: ghi hai lần đọc hoặc đọc gần đó thay vì thực hiện , sau đó tìm kiếm ở xa, sau đó tìm kiếm lại.)

Trên đĩa quay (từ tính), bạn có thể thấy một vài độ trễ tìm kiếm từ 7 đến 10 ms mỗi lần trước khi dữ liệu từ lệnh ghi SATA thực sự an toàn khi tắt nguồn, nếu có các lần đọc / ghi chờ xử lý trước khi ghi. (Một số câu trả lời khác cho câu hỏi này đi sâu vào chi tiết hơn về bộ đệm ghi đĩa và viết các rào cản mà các FS có thể sử dụng để tránh tham nhũng.)