Triết lý đằng sau việc trì hoãn ghi dữ liệu vào đĩa là gì?

Trong Linux, việc thực hiện xong một lệnh như cphoặc ddkhông có nghĩa là dữ liệu đã được ghi vào thiết bị. Ví dụ, người ta phải gọi synchoặc gọi chức năng "Xóa an toàn" hoặc "Đẩy ra" trên ổ đĩa.

Triết lý đằng sau một cách tiếp cận như vậy là gì? Tại sao dữ liệu không được ghi cùng một lúc? Không có nguy hiểm rằng việc ghi sẽ thất bại do lỗi I / O?

Triết lý đằng sau một cách tiếp cận như vậy là gì?

Hiệu quả (sử dụng tốt hơn các đặc tính đĩa) và hiệu suất (cho phép ứng dụng tiếp tục ngay sau khi ghi).

Tại sao dữ liệu không được ghi cùng một lúc?

Ưu điểm chính là HĐH được tự do sắp xếp lại và hợp nhất các hoạt động ghi liền kề để cải thiện việc sử dụng băng thông của chúng (ít hoạt động hơn và ít tìm kiếm hơn). Đĩa cứng hoạt động tốt hơn khi một số lượng nhỏ các hoạt động lớn được yêu cầu trong khi các ứng dụng có xu hướng cần một số lượng lớn các hoạt động nhỏ thay thế. Một tối ưu hóa rõ ràng khác là HĐH cũng có thể xóa tất cả trừ lần ghi cuối cùng khi cùng một khối được viết nhiều lần trong một khoảng thời gian ngắn hoặc thậm chí xóa một số ghi cùng nhau nếu tệp bị ảnh hưởng đã bị xóa trong thời gian đó.

Những ghi không đồng bộ được thực hiện sau khi các writecuộc gọi hệ thống đã trở lại. Đây là lợi thế thứ hai và nhiều người dùng nhất có thể nhìn thấy. Ghi không đồng bộ tăng tốc các ứng dụng vì chúng có thể tự do tiếp tục công việc mà không cần chờ dữ liệu thực sự nằm trên đĩa. Loại bộ đệm / bộ đệm tương tự cũng được triển khai cho các hoạt động đọc trong đó các khối đọc gần đây hoặc thường được giữ lại trong bộ nhớ thay vì được đọc lại từ đĩa.

Không có nguy hiểm rằng việc ghi sẽ thất bại do lỗi IO?

Không cần thiết. Điều đó phụ thuộc vào hệ thống tập tin được sử dụng và dự phòng tại chỗ. Một lỗi I / O có thể vô hại nếu dữ liệu có thể được lưu ở nơi khác. Các hệ thống tệp hiện đại như ZFS tự chữa lành các khối đĩa xấu. Cũng lưu ý rằng lỗi I / O không gặp sự cố hệ điều hành hiện đại. Nếu chúng xảy ra trong quá trình truy cập dữ liệu, chúng chỉ được báo cáo cho ứng dụng bị ảnh hưởng. Nếu chúng xảy ra trong quá trình truy cập siêu dữ liệu cấu trúc và khiến hệ thống tệp gặp rủi ro, nó có thể được truy cập lại chỉ đọc hoặc không thể truy cập được.

Ngoài ra còn có một rủi ro mất dữ liệu nhẹ trong trường hợp xảy ra sự cố hệ điều hành, mất điện hoặc lỗi phần cứng. Đây là lý do tại sao các ứng dụng phải chắc chắn 100% dữ liệu trên đĩa (ví dụ: cơ sở dữ liệu / ứng dụng tài chính) đang hoạt động kém hiệu quả hơn nhưng ghi đồng bộ an toàn hơn. Để giảm thiểu tác động hiệu suất, nhiều ứng dụng vẫn sử dụng ghi không đồng bộ nhưng cuối cùng đồng bộ hóa chúng khi người dùng lưu một cách rõ ràng một tệp (ví dụ: vim, bộ xử lý văn bản.)

Mặt khác, phần lớn người dùng và ứng dụng không cần và cũng không quan tâm đến sự an toàn mà ghi đồng bộ cung cấp. Nếu có sự cố hoặc mất điện, rủi ro duy nhất thường là mất mát ở mức tồi tệ nhất trong 30 giây cuối cùng của dữ liệu. Trừ khi có một giao dịch tài chính liên quan hoặc một cái gì đó tương tự có nghĩa là chi phí lớn hơn 30 giây thời gian của họ, mức tăng lớn trong hiệu suất (không phải là ảo tưởng nhưng rất thực tế) việc viết không đồng bộ cho phép phần lớn vượt trội so với rủi ro.

Cuối cùng, ghi đồng bộ không đủ để bảo vệ dữ liệu được ghi. Nếu ứng dụng của bạn thực sự cần phải chắc chắn rằng dữ liệu của họ không thể bị mất bất cứ điều gì xảy ra, sao chép dữ liệu trên nhiều đĩa và trên nhiều vị trí địa lý cần được đặt để chống lại các thảm họa như hỏa hoạn, lũ lụt, v.v.

Nó chỉ đơn giản là tạo ảo giác về tốc độ cho các chương trình mà thực tế không phải đợi cho đến khi viết xong. Gắn hệ thống tệp của bạn ở chế độ đồng bộ hóa (cung cấp cho bạn khả năng ghi tức thì) và xem mọi thứ chậm như thế nào.

Đôi khi các tệp chỉ tồn tại tạm thời ... một chương trình thực hiện một số công việc và xóa tệp ngay sau khi hoàn thành công việc. Nếu bạn trì hoãn những bài viết đó, bạn có thể thoát khỏi việc không bao giờ viết chúng ở nơi đầu tiên.

Không có nguy hiểm rằng việc ghi sẽ thất bại do lỗi IO?

Ồ, hoàn toàn. Trong trường hợp như vậy, thông thường toàn bộ hệ thống tập tin sẽ chuyển sang chế độ chỉ đọc và mọi thứ thật kinh khủng. Nhưng điều đó hiếm khi xảy ra, không có điểm nào làm mất đi lợi thế về hiệu suất nói chung.

I / O được đệm không đồng bộ, được sử dụng trước Linux và thậm chí trước Unix. Unix đã có nó, và vì vậy có tất cả các nhánh của nó.

Dưới đây là những gì Ritchie và Thompson đã viết trong bài báo CACM của họ Hệ thống chia sẻ thời gian UNIX :

Đối với người dùng, cả việc đọc và ghi tệp dường như là đồng bộ và không có bộ đệm. Đó là ngay sau khi trả về từ một cuộc gọi đọc, dữ liệu có sẵn và ngược lại sau khi viết, không gian làm việc của người dùng có thể được sử dụng lại. Trong thực tế, hệ thống duy trì một cơ chế đệm khá phức tạp, giúp giảm đáng kể số lượng thao tác I / O cần thiết để truy cập một tệp.

Trong câu hỏi của bạn, bạn cũng đã viết:

Không có nguy hiểm rằng việc ghi sẽ thất bại do lỗi IO?

Có, viết có thể thất bại và chương trình có thể không bao giờ biết về nó. Mặc dù không bao giờ là một điều tốt, nhưng các tác động của điều này có thể được giảm thiểu trong trường hợp lỗi I / O tạo ra sự hoảng loạn hệ thống (trên một số hệ điều hành này có thể định cấu hình - thay vì hoảng loạn, hệ thống có thể tiếp tục chạy nhưng hệ thống tệp bị ảnh hưởng là không đếm được hoặc gắn chỉ đọc). Người dùng sau đó có thể được thông báo rằng dữ liệu trên hệ thống tập tin đó bị nghi ngờ. Và một ổ đĩa có thể được theo dõi một cách chủ động để xem liệu danh sách lỗi phát triển của nó có tăng nhanh hay không, đó là một dấu hiệu cho thấy ổ đĩa bị lỗi.

BSD đã thêm lệnh fsyncgọi hệ thống để chương trình có thể chắc chắn rằng dữ liệu tệp của nó đã được ghi hoàn toàn vào đĩa trước khi tiếp tục và các hệ thống Unix tiếp theo đã cung cấp các tùy chọn để thực hiện ghi đồng bộ. GNU dd có một tùy chọn conv=fsyncđể đảm bảo rằng tất cả dữ liệu đã được ghi ra trước khi lệnh thoát. Nó rất hữu ích khi ghi vào các ổ flash di động chậm, trong đó dữ liệu được đệm có thể mất vài phút để ghi ra.

Một nguồn tham nhũng tập tin khác là tắt hệ thống đột ngột, ví dụ do mất điện. Hầu như tất cả các hệ thống hiện tại đều hỗ trợ cờ sạch / bẩn trong hệ thống tệp của chúng. Cờ được đặt thành sạch khi không còn dữ liệu nào được ghi ra và hệ thống tập tin sắp bị ngắt kết nối, thường là trong khi tắt hệ thống hoặc bằng cách gọi thủ công umount. Các hệ thống thường sẽ chạy fsckkhi khởi động lại nếu chúng phát hiện ra rằng các hệ thống tập tin không được tắt sạch.

Nhiều câu trả lời hay, nhưng hãy để tôi thêm một điều nữa ... Hãy nhớ rằng Unix là một hệ thống đa quy trình và nhiều người dùng, vì vậy nhiều người dùng sẽ cố gắng thực hiện các thao tác tệp (đặc biệt là) tại (gần như) cùng một lúc Với các ổ cứng chậm cũ - có thể được gắn qua mạng - điều này không chỉ mất thời gian (mà các chương trình về cơ bản sẽ bị khóa và người dùng phải chờ), nhưng gây ra rất nhiều chuyển động đọc / ghi của đĩa qua lại.

Vì vậy, thay vào đó, các tệp chờ ghi được lưu trong bộ nhớ trong một thời gian và được sắp xếp sau khi chúng kết thúc trên đĩa ... và khi bộ đệm đầy - hoặc trình nền đồng bộ hóa đĩa đã chờ số giây cần thiết (tôi nghĩ nó thường là khoảng 30 giây) - toàn bộ bộ đệm được ghi ra đĩa "theo thứ tự", với đầu ghi chỉ phải thực hiện một chuyển động quét liên tục, ghi các tệp vào đĩa như nó đã đi ... thay vì nhảy khắp nơi.

Nguồn của các đĩa nhanh ngày nay - không đề cập đến các thiết bị trạng thái rắn - mức tăng ít hơn nhiều ... một cách bí mật trên hệ thống linux tại nhà, nơi chỉ có một người dùng làm việc tại một thời điểm và chỉ với một vài chương trình.

Dù sao, sự kết hợp của việc đọc dự đoán bằng cách đọc (vào bộ đệm / bộ đệm) nhiều hơn so với yêu cầu - và sắp xếp dữ liệu đang chờ để viết, vì vậy nó có thể được viết bằng "một chuyển động" - thực sự là một ý tưởng rất tốt ở thời gian, đặc biệt là trên các hệ thống có nhiều người đọc và viết bởi nhiều người dùng.

Nó không dành riêng cho Linux và nó được gọi là bộ đệm trang (mà Linux hoạt động khá tốt). Xem thêm http://linuxHRyram.com/ ; Vì vậy, nếu một tệp được ghi, sau đó đọc lại một vài giây sau đó, thường thì không cần đĩa I / O.

Ưu điểm chính là trên nhiều hệ thống, có rất nhiều RAM và một số có thể được sử dụng làm bộ đệm của kernel. Vì vậy, một số hoạt động tập tin có thể có lợi nhuận của bộ nhớ đệm này. Ngoài ra, thời gian vào / ra của đĩa chậm hơn rất nhiều (thường là hàng nghìn lần đối với SDD và chậm hơn gần một triệu lần đối với đĩa cứng cơ học) so với RAM.

Mã ứng dụng có thể đưa ra gợi ý về bộ đệm này: xem ví dụ posix_fadvise (2) & madvise (2)

Đĩa quay chậm hơn RAM. Chúng tôi sử dụng bộ nhớ đệm đọc / ghi để 'ẩn' thực tế này.

Điều hữu ích khi ghi IO là nó không yêu cầu IO đĩa xảy ra ngay lập tức - không giống như đọc, nơi bạn không thể trả lại dữ liệu cho người dùng cho đến khi việc đọc hoàn tất trên đĩa.

Do đó, ghi hoạt động trong một ràng buộc thời gian mềm - miễn là thông lượng duy trì của chúng tôi không vượt quá đĩa của chúng tôi, chúng tôi có thể ẩn rất nhiều hình phạt hiệu suất trong bộ đệm ghi.

Và chúng ta cần phải ghi bộ đệm - đĩa quay tương đối chậm. Nhưng để làm các loại RAID hiện đại có một hình phạt đáng kể cho hoạt động.

Ví dụ, RAID 6, để hoàn thành một lần ghi IO phải:

• Đọc khối cập nhật
• đọc chẵn lẻ1
• đọc chẵn lẻ 2
• viết khối mới
• viết chẵn lẻ 1
• viết chẵn lẻ 2

Do đó, mỗi lần ghi thực sự là 6 thao tác IO - và đặc biệt khi bạn có các ổ đĩa chậm như ổ đĩa SATA lớn, điều này trở nên cực kỳ tốn kém.

Nhưng có một giải pháp dễ dàng tốt đẹp - viết kết lại. Nếu bạn có thể xây dựng một bản ghi 'toàn dải' trong bộ đệm, bạn không cần phải đọc chẵn lẻ từ đĩa của mình - bạn có thể tính toán nó dựa trên những gì bạn có trong bộ nhớ.

Rất mong muốn làm điều này, bởi vì sau đó bạn không còn phải khuếch đại ghi nữa. Thật vậy, bạn có thể bị phạt ghi thấp hơn RAID 1 + 0.

Xem xét:

RAID 6, 8 + 2 - 10 cọc.

8 khối dữ liệu liên tiếp để ghi - tính toán chẵn lẻ trong bộ đệm và ghi một khối vào mỗi đĩa. 10 viết trên 8, có nghĩa là một hình phạt viết là 1,25. 10 đĩa RAID 1 + 0 vẫn có mức phạt ghi là 2 (vì bạn phải ghi vào từng tệp con). Vì vậy, trong kịch bản này, bạn thực sự có thể làm cho RAID 6 hoạt động tốt hơn RAID1 + 0. Trong sử dụng trong thế giới thực, bạn sẽ có thêm một chút cấu hình IO hỗn hợp.

Vì vậy, bộ nhớ đệm ghi có một sự khác biệt lớn đối với hiệu suất cảm nhận của các bộ RAID - bạn có thể ghi ở tốc độ RAM và có mức phạt ghi thấp - cải thiện thông lượng duy trì của bạn nếu bạn làm điều đó.

Và nếu bạn không, bạn phải chịu hiệu năng chậm chạp của SATA, nhưng nhân nó lên 6 và thêm một số tranh chấp trong đó. Bộ nhớ cache RAID 10 chiều của bạn mà không cần ghi bộ nhớ đệm sẽ nhanh hơn một chút so với một ổ đĩa không có RAID ... nhưng không nhiều lắm.

Bạn có một rủi ro mặc dù - như bạn lưu ý - mất điện có nghĩa là mất dữ liệu. Bạn có thể giảm thiểu điều này bằng cách chu kỳ xóa bộ đệm, sao lưu bộ nhớ cache hoặc sử dụng SSD hoặc bộ đệm không biến động khác.

Không có câu trả lời nào khác đề cập đến việc phân bổ chậm trễ . XFS, ext4, BTRFS và ZFS đều sử dụng nó. XFS đã sử dụng nó từ trước khi ext4 tồn tại, vì vậy tôi sẽ sử dụng nó làm ví dụ:

XFS thậm chí không quyết định nơi đặt dữ liệu cho đến khi viết ra. Phân bổ trễ cung cấp cho người cấp phát nhiều thông tin hơn để dựa trên các quyết định của mình. Khi một tệp được ghi lần đầu tiên, không có cách nào để biết đó sẽ là tệp 4k hay tệp 1G và vẫn đang phát triển. Nếu có 10G không gian trống liền kề ở đâu đó, đặt tệp 4k vào đầu của nó sẽ không tốt. Đặt tệp lớn vào đầu một không gian trống lớn sẽ giảm sự phân mảnh.

Tất cả các câu trả lời khác ở đây đều ở mức tối thiểu chính xác cho trường hợp bình thường và tôi khuyên bạn nên đọc bất kỳ câu trả lời nào trước tôi, nhưng bạn đã đề cập đến dd và dd có một trường hợp sử dụng điển hình có thể không liên quan đến ghi bộ đệm. Ghi bộ nhớ đệm được thực hiện chủ yếu ở cấp hệ thống tập tin. Các thiết bị thô thường không ghi bộ nhớ đệm (nhiều trình điều khiển thiết bị như đột kích hoặc lvm là một quả bóng sáp khác). Vì dd thường được sử dụng với các thiết bị khối thô, nó cung cấp các bs và các tùy chọn liên quan để cho phép ghi lớn để có hiệu suất tốt hơn trên các thiết bị thô. Điều này không hữu ích khi cả hai điểm cuối là các tệp thông thường (mặc dù ghi lớn sử dụng ít cuộc gọi hệ thống hơn trong trường hợp này). Điểm chung khác nơi điều này đặc biệt hiển thị là với gói mtools là triển khai hệ thống tệp chất béo không gian người dùng. sử dụng mtools với ổ đĩa mềm luôn cảm thấy chậm chạp vô cùng vì các công cụ hoàn toàn đồng bộ và ổ đĩa mềm rất chậm. Việc gắn đĩa mềm và sử dụng hệ thống tập tin chất béo hạt nhân sẽ phản ứng nhanh hơn nhiều, ngoại trừ việc đồng bộ hóa (và rất quan trọng đối với nó là cách đó để ngăn ngừa mất dữ liệu, đặc biệt đối với các thiết bị di động như đĩa mềm). Chỉ có một vài chương trình khác mà tôi nhận thấy thường xuyên được sử dụng với các thiết bị thô như cơ sở dữ liệu được cấu hình đặc biệt (thực hiện bộ nhớ đệm ghi riêng của họ), tar, và các công cụ hệ thống tập tin và thiết bị đặc biệt như chdsk, mkfs và mt. Việc gắn đĩa mềm và sử dụng hệ thống tập tin chất béo hạt nhân sẽ phản ứng nhanh hơn nhiều, ngoại trừ việc đồng bộ hóa (và rất quan trọng đối với nó là cách đó để ngăn ngừa mất dữ liệu, đặc biệt đối với các thiết bị di động như đĩa mềm). Chỉ có một vài chương trình khác mà tôi nhận thấy thường xuyên được sử dụng với các thiết bị thô như cơ sở dữ liệu được cấu hình đặc biệt (thực hiện bộ nhớ đệm ghi riêng của họ), tar, và các công cụ hệ thống tập tin và thiết bị đặc biệt như chdsk, mkfs và mt. Việc gắn đĩa mềm và sử dụng hệ thống tập tin chất béo hạt nhân sẽ phản ứng nhanh hơn nhiều, ngoại trừ việc đồng bộ hóa (và rất quan trọng đối với nó là cách đó để ngăn ngừa mất dữ liệu, đặc biệt đối với các thiết bị di động như đĩa mềm). Chỉ có một vài chương trình khác mà tôi nhận thấy thường xuyên được sử dụng với các thiết bị thô như cơ sở dữ liệu được cấu hình đặc biệt (thực hiện bộ nhớ đệm ghi riêng của họ), tar, và các công cụ hệ thống tập tin và thiết bị đặc biệt như chdsk, mkfs và mt.

Các triết lý là không an toàn theo mặc định.

Có hai chiến lược hợp lý và rõ ràng có thể xảy ra: xóa ghi vào đĩa ngay lập tức hoặc trì hoãn ghi. UNIX trong lịch sử đã chọn cái sau. Vì vậy, để có được sự an toàn, bạn cần phải gọi fsyncsau đó.

Tuy nhiên, bạn có thể chỉ định trả trước an toàn bằng cách gắn thiết bị có tùy chọn synchoặc mỗi tệp bằng cách mở chúng bằng O_SYNC.

Hãy nhớ rằng UNIX được thiết kế cho các chuyên gia máy tính. "An toàn theo mặc định" không phải là một cân nhắc. An toàn có nghĩa là I / O chậm hơn, và những hệ thống đầu tiên đó thực sự có I / O chậm làm cho tỷ lệ giá cao. Thật không may, cả UNIX và Linux đều không chuyển sang mặc định an toàn, mặc dù đây là một thay đổi không phá vỡ.

Nó giao dịch một lượng nhỏ độ tin cậy để tăng thông lượng.

Giả sử, ví dụ, một chương trình nén video. Với việc viết chậm ("viết lại"):

1. dành 10ms nén khung
2. vấn đề ghi khung vào đĩa
3. chờ 10ms để đĩa xác nhận ghi xong
4. GOTO 1

Đấu với

1. dành 10ms nén khung
2. vấn đề ghi khung vào đĩa (hoàn thành trong nền)
3. GOTO 1

Phiên bản thứ hai xuất hiện nhanh gấp đôi vì nó có thể sử dụng CPU và đĩa cùng một lúc, trong khi phiên bản đầu tiên luôn chờ đợi cái này hay cái khác.

Nói chung, bạn muốn ghi lại cho các hoạt động phát trực tuyến và các hoạt động tệp hàng loạt và ghi lại cho cơ sở dữ liệu và các ứng dụng giống như cơ sở dữ liệu.

Trong nhiều ứng dụng, các thiết bị lưu trữ sẽ liên tục bận đọc dữ liệu. Nếu một hệ thống luôn có thể trì hoãn ghi cho đến khi thiết bị lưu trữ không bận đọc dữ liệu, thì theo quan điểm của ứng dụng, việc ghi sẽ mất 0 thời gian để hoàn thành. Các tình huống duy nhất trong đó viết sẽ không tức thời là:

1. Viết bộ đệm điền đến mức không thể chấp nhận yêu cầu ghi chậm hơn cho đến khi ghi thực sự hoàn thành.

2. Cần phải tắt hoặc xóa thiết bị đang chờ xử lý.

3. Một ứng dụng đặc biệt yêu cầu xác nhận rằng một bài viết đã thực sự hoàn thành.

Thật vậy, chỉ vì những yêu cầu trên mà việc viết cần phải thực sự diễn ra. Mặt khác, nói chung không có lý do gì để không thực hiện bất kỳ thao tác ghi nào đang chờ xử lý vào những thời điểm khi thiết bị không hoạt động, do đó, rất nhiều hệ thống thực hiện chúng sau đó.

Ngoài ra còn có điều này:

Viết "Hi, Joe Moe"
nhanh hơn:
Viết "Hi,"
Viết "Joe"
Viết "Moe"

Và cũng:

Viết "Xin chào, bạn thế nào?"
nhanh hơn:
Viết "Xin chào, chuyện gì thế?"
Xóa mà
viết "Howdy, bạn có khỏe không?"
Xóa mà
viết "Xin chào, bạn thế nào?"

Sẽ tốt hơn cho việc sửa đổi và tổng hợp xảy ra trong RAM so với trên đĩa. Batching đĩa ghi giải phóng các nhà phát triển ứng dụng khỏi những mối quan tâm như vậy.