(176/211) 3952 - Crash safety

Currently I am working on an automated tool to detect the crash related file-system bugs.

If we are saving a file "file", I traced down to the following process:

1. there is only {file}
2. a save file is written {file, #file#save}
3. a backup file is written {file, file~, #file#save}
4. file is deleted {file~, #file#save}
5. rename back {file, file~}

If after (4) the system crashes, there could be nothing useful left in the file-system -- user's file can be gone forever, if there is no file~ in the file-system. This surprising result is due to the deletion (meta-data operation) can be reordered with the data writes. Here is a paper FYI: https://www.usenix.org/node/186195 (there is a link to a PDF file, see Table 1 in page 436). We confirmed this can happen with the tool.

Whenever a user's file is to be deleted, it is safer to persist the previously written backup/save file, by (1) flush any buffered writer's buffer if exists; (2) call fsync() on that file descriptor. This ensures the previous data writes not reordered with further operations.

p.s. When I am going into the source code, I actually did not find the file is being deleted anywhere, but both the tool and strace reported the unlink system call. You sure have more knowledge than me on the code base.

Thank you for your attention.

==============================

Version: 5.1 (I diffed the classes, it seems 5.1 and 5.3 share the same code on file saving, with minor changes)
Affected file-system: ext3, ext4

Comments