[c] Linux에서 쓰기 손실을 유발하는 I / O 오류에 대처하기위한 프로그램 작성

fsync()-EIO커널이 쓰기를 잃은 경우 반환

(참고 : 초기 부분은 이전 커널을 참조하며 최신 커널을 반영하도록 아래에서 업데이트 됨)

실패시 비동기 버퍼 쓰기 가 파일의 실패한 더티 버퍼 페이지에 플래그를 end_buffer_async_write(...)설정하는-EIO 것처럼 보입니다 .

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

다음에 의해 감지되는 wait_on_page_writeback_range(...)호출로 do_sync_mapping_range(...)호출로 sys_sync_file_range(...)호출으로 sys_sync_file_range2(...)C 라이브러리 호출을 구현하는 fsync().

하지만 한 번만!

에 대한 의견 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.

fsync()반환 -EIO하거나 (맨 페이지에 문서화되어 있지 않은 경우 ) 오류 상태-ENOSPC 를 지우 므로 fsync()페이지가 작성되지 않은 경우에도 후속 보고서에서 성공을보고합니다.

wait_on_page_writeback_range(...) 테스트 할 때 오류 비트를 충분히 지 웁니다 .

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;

따라서 응용 프로그램 fsync()이 성공할 때까지 재 시도 할 수 있고 데이터가 디스크에 있음을 신뢰할 수 있다고 예상 하면 매우 잘못됩니다.

이것이 DBMS에서 찾은 데이터 손상의 원인이라고 확신합니다. 다시 시도 fsync()하고 성공하면 모든 것이 잘 될 것이라고 생각합니다.

이것이 허용됩니까?

에 POSIX / SUS 문서는fsync() 정말이 방법을 지정하지 :

fsync () 함수가 실패하면 미해결 I / O 작업이 완료된 것은 아닙니다.

Linux의 맨 페이지는fsync() 장애 발생시 어떤 일도 일어나지 않습니다.

따라서 fsync()오류 의 의미 는 “당신의 글에 무슨 일이 일어 났는지, 전혀 작동하지 않았는지, 더 확실하게 다시 시도하는 것이 좋습니다”라는 것 같습니다.

최신 커널

를 통해 페이지의 4.9 end_buffer_async_write세트 -EIO에서 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);

동기화 측면에서는 구조가 비슷 하기는하지만 비슷하다고 생각합니다. filemap_check_errors에서 mm/filemap.c지금 수행합니다

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

이는 거의 같은 효과가 있습니다. 오류 검사는 모두 잘 수행 filemap_check_errors되는 것으로 보입니다 .

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

btrfs랩톱에서 사용 하고 있지만 ext4테스트를 위해 루프백을 만들고 /mnt/tmp성능 프로브를 설정할 때 :

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

다음과 같은 호출 스택을 찾습니다 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

읽기는 현대 커널이 동일하게 동작한다는 것을 암시합니다.

이 경우 있음을 의미하는 것 fsync()(또는 아마도 write()나 close()) 반환 -EIO, 파일이 마지막으로 성공적으로 할 때 사이에 정의되지 않은 상태에서 fsync()d 또는 close()그와 가장 최근에 거라고 write()열 상태를.

테스트

이 동작을 보여주기 위해 테스트 사례를 구현했습니다 .

시사점

DBMS는 응급 복구를 입력하여 이에 대처할 수 있습니다. 일반 사용자 응용 프로그램은이 문제에 어떻게 대처해야합니까? fsync()man 페이지는 뜻한다는 경고를주지 않는다 “fsync를-경우 – 당신 느낌 같은-은”내가이 기대하는 많은 응용 프로그램의이 문제에 잘 대처하지 않습니다.

버그 리포트

• https://bugzilla.kernel.org/show_bug.cgi?id=194755
• https://bugzilla.kernel.org/show_bug.cgi?id=194757

추가 자료

lwn.net은 “개선 된 블록 레이어 오류 처리”기사에서 이에 대해 언급했습니다 .

postgresql.org 메일 링리스트 쓰레드 .

---

답변