Viết chương trình để đối phó với lỗi I / O gây mất ghi trên Linux

TL; DR: Nếu nhân Linux mất ghi I / O được đệm , có cách nào để ứng dụng tìm ra không?

Tôi biết bạn phải fsync()tập tin (và thư mục mẹ của nó) cho độ bền . Câu hỏi đặt ra là nếu kernel mất bộ đệm bẩn đang chờ ghi do lỗi I / O, làm thế nào để ứng dụng có thể phát hiện ra điều này và phục hồi hoặc hủy bỏ?

Hãy nghĩ rằng các ứng dụng cơ sở dữ liệu, vv, trong đó thứ tự ghi và viết độ bền có thể rất quan trọng.

Mất viết? Làm sao?

Trong một số trường hợp, lớp khối của hạt nhân Linux có thể bị mất các yêu cầu I / O được đệm đã được gửi thành công write(), pwrite()v.v., với một lỗi như:

Buffer I/O error on device dm-0, logical block 12345
lost page write due to I/O error on dm-0

(Xem end_buffer_write_sync(...)và end_buffer_async_write(...)trongfs/buffer.c ).

Trên các hạt nhân mới hơn, thay vào đó, lỗi sẽ chứa "ghi trang không đồng bộ bị mất" , như:

Buffer I/O error on dev dm-0, logical block 12345, lost async page write

Vì ứng dụng write()sẽ quay trở lại mà không có lỗi, nên dường như không có cách nào để báo cáo lỗi về ứng dụng.

Phát hiện chúng?

Tôi không quen thuộc với các nguồn kernel, nhưng tôi nghĩ rằng nó đặt AS_EIOtrên bộ đệm không được ghi ra nếu nó thực hiện ghi async:

    set_bit(AS_EIO, &page->mapping->flags);
    set_buffer_write_io_error(bh);
    clear_buffer_uptodate(bh);
    SetPageError(page);

nhưng nó không rõ ràng với tôi nếu hoặc làm thế nào ứng dụng có thể tìm hiểu về điều này khi nó fsync()là tệp để xác nhận nó trên đĩa.

Dường như wait_on_page_writeback_range(...)trongmm/filemap.c sức bởi do_sync_mapping_range(...)trongfs/sync.c đó là rẽ gọi bằng sys_sync_file_range(...). Nó trả về -EIOnếu một hoặc nhiều bộ đệm không thể được viết.

Nếu, như tôi đoán, điều này lan truyền đến fsync()kết quả, sau đó nếu ứng dụng hoảng loạn và giải cứu nếu nó bị lỗi I / O fsync()và biết cách thực hiện lại công việc của nó khi được khởi động lại, điều đó có đủ an toàn không?

Có lẽ không có cách nào để ứng dụng biết được byte nào trong tệp tương ứng với các trang bị mất để nó có thể viết lại chúng nếu biết, nhưng nếu ứng dụng lặp lại tất cả công việc đang chờ xử lý của nó kể từ lần thành công cuối cùng fsync()của tệp và điều đó viết lại bất kỳ bộ đệm kernel bẩn nào tương ứng với ghi bị mất đối với tệp, sẽ xóa mọi cờ lỗi I / O trên các trang bị mất và cho phép tiếp theo fsync()hoàn thành - phải không?

Sau đó, có trường hợp nào khác, vô hại, nơi fsync()có thể trở lại -EIOnơi bảo lãnh và làm lại công việc sẽ quá quyết liệt?

Tại sao?

Tất nhiên lỗi như vậy không nên xảy ra. Trong trường hợp này, lỗi phát sinh từ sự tương tác đáng tiếc giữa dm-multipathmặc định của trình điều khiển và mã cảm giác được SAN sử dụng để báo cáo lỗi không phân bổ dung lượng lưu trữ được cung cấp mỏng. Nhưng đây không phải là trường hợp duy nhất có thể xảy ra - tôi cũng đã thấy các báo cáo về nó từ LVM được cung cấp mỏng chẳng hạn, như được sử dụng bởi libvirt, Docker, v.v. Một ứng dụng quan trọng như cơ sở dữ liệu nên cố gắng đối phó với các lỗi như vậy, thay vì mù quáng tiếp tục như thể tất cả đều ổn.

Nếu kernel nghĩ rằng không sao để mất ghi mà không chết với kernel, thì các ứng dụng phải tìm cách đối phó.

Tác động thực tế là tôi đã tìm thấy một trường hợp trong đó một vấn đề đa luồng với SAN gây ra mất ghi đã hạ cánh gây ra tham nhũng cơ sở dữ liệu vì DBMS không biết rằng bài viết của nó đã thất bại. Không vui.

fsync()trả về -EIOnếu kernel bị mất ghi

(Lưu ý: phần đầu tham khảo các hạt nhân cũ hơn; được cập nhật bên dưới để phản ánh các hạt nhân hiện đại)

Dường như lỗi ghi bộ đệm async trong các end_buffer_async_write(...)lỗi đặt -EIOcờ trên trang bộ đệm bẩn không thành công cho tệp :

set_bit(AS_EIO, &page->mapping->flags);
set_buffer_write_io_error(bh);
clear_buffer_uptodate(bh);
SetPageError(page);

sau đó được phát hiện bởi wait_on_page_writeback_range(...)như gọi bằng do_sync_mapping_range(...)như gọi bằng sys_sync_file_range(...)như gọi bằng sys_sync_file_range2(...)để thực hiện các cuộc gọi thư viện C fsync().

Nhưng chỉ một lần!

Nhận xét này về sys_sync_file_range

168  * SYNC_FILE_RANGE_WAIT_BEFORE and SYNC_FILE_RANGE_WAIT_AFTER will detect any
169  * I/O errors or ENOSPC conditions and will return those to the caller, after
170  * clearing the EIO and ENOSPC flags in the address_space.

gợi ý rằng khi fsync()trả về -EIOhoặc (không có giấy tờ trong trang chủ) -ENOSPC, nó sẽ xóa trạng thái lỗi để tiếp theo fsync()sẽ báo cáo thành công mặc dù các trang không bao giờ được viết.

Chắc chắn đủ để wait_on_page_writeback_range(...) xóa các bit lỗi khi nó kiểm tra chúng :

301         /* Check for outstanding write errors */
302         if (test_and_clear_bit(AS_ENOSPC, &mapping->flags))
303                 ret = -ENOSPC;
304         if (test_and_clear_bit(AS_EIO, &mapping->flags))
305                 ret = -EIO;

Vì vậy, nếu ứng dụng mong đợi nó có thể thử lại fsync()cho đến khi thành công và tin tưởng rằng dữ liệu trên đĩa, thì đó là sai lầm khủng khiếp.

Tôi khá chắc chắn đây là nguồn gốc của sự hỏng dữ liệu mà tôi tìm thấy trong DBMS. Nó thử lại fsync()và nghĩ rằng tất cả sẽ tốt khi nó thành công.

Điều này có được phép không?

Các tài liệu POSIX / SuS trênfsync() không thực sự chỉ định theo cách này:

Nếu chức năng fsync () không thành công, các hoạt động I / O nổi bật không được đảm bảo đã hoàn thành.

Trang con người của Linuxfsync() không nói gì về những gì xảy ra khi thất bại.

Vì vậy, có vẻ như ý nghĩa của fsync()lỗi là "dunno những gì đã xảy ra với bài viết của bạn, có thể đã hoạt động hoặc không, tốt hơn là thử lại để chắc chắn".

Hạt nhân mới hơn

Trên 4.9 end_buffer_async_writebộ -EIOtrên trang, chỉ cần thông qua mapping_set_error.

    buffer_io_error(bh, ", lost async page write");
    mapping_set_error(page->mapping, -EIO);
    set_buffer_write_io_error(bh);
    clear_buffer_uptodate(bh);
    SetPageError(page);

Về mặt đồng bộ tôi nghĩ nó tương tự nhau, mặc dù cấu trúc bây giờ khá phức tạp để theo dõi. filemap_check_errorstrong mm/filemap.cgiờ làm:

    if (test_bit(AS_EIO, &mapping->flags) &&
        test_and_clear_bit(AS_EIO, &mapping->flags))
            ret = -EIO;

trong đó có nhiều tác dụng tương tự. Kiểm tra lỗi dường như tất cả đều trải qua filemap_check_errorsmà kiểm tra và rõ ràng:

    if (test_bit(AS_EIO, &mapping->flags) &&
        test_and_clear_bit(AS_EIO, &mapping->flags))
            ret = -EIO;
    return ret;

Tôi đang sử dụng btrfstrên máy tính xách tay của mình, nhưng khi tôi tạo một ext4loopback để thử nghiệm /mnt/tmpvà thiết lập một đầu dò hoàn hảo trên nó:

sudo dd if=/dev/zero of=/tmp/ext bs=1M count=100
sudo mke2fs -j -T ext4 /tmp/ext
sudo mount -o loop /tmp/ext /mnt/tmp

sudo perf probe filemap_check_errors

sudo perf record -g -e probe:end_buffer_async_write -e probe:filemap_check_errors dd if=/dev/zero of=/mnt/tmp/test bs=4k count=1 conv=fsync

Tôi tìm thấy ngăn xếp cuộc gọi sau đây trong perf report -T:

        ---__GI___libc_fsync
           entry_SYSCALL_64_fastpath
           sys_fsync
           do_fsync
           vfs_fsync_range
           ext4_sync_file
           filemap_write_and_wait_range
           filemap_check_errors

Đọc qua gợi ý rằng yeah, hạt nhân hiện đại hành xử giống nhau.

Điều này dường như có nghĩa là nếu fsync()(hoặc có lẽ write()hoặc close()) trở lại -EIO, tệp ở trạng thái không xác định giữa thời điểm bạn thành công fsync()d hoặc close()d nó và write()mười trạng thái gần đây nhất của nó .

Kiểm tra

Tôi đã thực hiện một trường hợp thử nghiệm để chứng minh hành vi này .

Hàm ý

Một DBMS có thể đối phó với điều này bằng cách vào phục hồi sự cố. Làm thế nào trên trái đất là một ứng dụng người dùng bình thường được cho là để đối phó với điều này? Các fsync()trang người đàn ông không đưa ra cảnh báo rằng nó có nghĩa là "fsync-if-you-cảm-như-nó" và tôi hy vọng một nhiều các ứng dụng sẽ không đối phó tốt với hành vi này.

Báo cáo lỗi

• https://ormszilla.kernel.org/show_orms.cgi?id=194755
• https://ormszilla.kernel.org/show_orms.cgi?id=194757

đọc thêm

lwn.net đã chạm vào điều này trong bài viết "Cải thiện xử lý lỗi lớp khối" .

postgresql.org chủ đề danh sách gửi thư .

Vì write () của ứng dụng sẽ được trả về mà không có lỗi, nên dường như không có cách nào để báo cáo lại lỗi cho ứng dụng.

Tôi không đồng ý. writecó thể trả về mà không có lỗi nếu ghi đơn giản là được xếp hàng, nhưng lỗi sẽ được báo cáo trong thao tác tiếp theo sẽ yêu cầu ghi thực tế trên đĩa, có nghĩa là tiếp theo fsync, có thể là ghi sau nếu hệ thống quyết định xóa bộ đệm và tại ít nhất trên tập tin cuối cùng đóng.

Đó là lý do tại sao ứng dụng cần thiết để kiểm tra giá trị trả về gần để phát hiện các lỗi ghi có thể xảy ra.

Nếu bạn thực sự cần có khả năng xử lý lỗi thông minh, bạn phải cho rằng mọi thứ được viết từ lần thành công cuối cùng fsync có thể đã thất bại và trong tất cả những điều đó ít nhất đã xảy ra.

write(2) cung cấp ít hơn bạn mong đợi. Trang người đàn ông rất cởi mở về ngữ nghĩa của một write()cuộc gọi thành công :

Hoàn trả thành công từ write()không đảm bảo rằng dữ liệu đã được cam kết vào đĩa. Trong thực tế, trên một số triển khai lỗi, thậm chí không đảm bảo rằng không gian đã được dành riêng cho dữ liệu. Cách duy nhất để chắc chắn là gọi fsync(2) sau khi bạn viết xong tất cả dữ liệu của mình.

Chúng ta có thể kết luận rằng thành công write()chỉ có nghĩa là dữ liệu đã đạt đến các cơ sở đệm của kernel. Nếu vẫn tồn tại bộ đệm thất bại, lần truy cập tiếp theo vào bộ mô tả tệp sẽ trả về mã lỗi. Như là phương sách cuối cùng có thể close(). Trang man của closelệnh gọi hệ thống (2) chứa câu sau:

Hoàn toàn có thể xảy ra lỗi trong writethao tác (2) trước đó được báo cáo đầu tiên tại Final close().

Nếu ứng dụng của bạn cần duy trì dữ liệu, hãy ghi lại, nó phải sử dụng fsync/ fsyncdatathường xuyên:

fsync()chuyển ("tuôn ra") tất cả dữ liệu trong lõi đã sửa đổi của (nghĩa là các trang bộ đệm bộ đệm đã sửa đổi cho) tệp được mô tả bởi tệp mô tả tệp fd vào thiết bị đĩa (hoặc thiết bị lưu trữ vĩnh viễn khác) để có thể lấy tất cả thông tin thay đổi ngay cả sau khi hệ thống bị sập hoặc được khởi động lại. Điều này bao gồm ghi thông qua hoặc xóa bộ đệm đĩa nếu có. Các cuộc gọi chặn cho đến khi thiết bị báo cáo rằng việc chuyển đã hoàn thành.

Sử dụng cờ O_SYNC khi bạn mở tệp. Nó đảm bảo dữ liệu được ghi vào đĩa.

Nếu điều này không làm bạn hài lòng, sẽ không có gì.

Kiểm tra giá trị trả về của đóng. đóng có thể thất bại trong khi ghi đệm xuất hiện để thành công.