Re: Inconsistent behavior of fsync in btrfs

[Jayashree Mohan <jayashree2912@gmail.com>]

Thanks Chris and Ted for putting down the expected fsync behaviour of
btrfs and ext4 clearly. This sort of information is not documented
anywhere; it would be really useful if all major filesystems
explicitly stated what fsync behavior to expect. Filesystems
definitely seem to provide more guarantees than POSIX and it would of
great help to researchers and developers, if you all documented what
guarantees we can expect from each filesystem.

On Fri, Apr 27, 2018 at 3:53 PM, Theodore Y. Ts'o <tytso@mit.edu> wrote:
> On Fri, Apr 27, 2018 at 11:33:29AM -0600, Chris Mason wrote:
>> My goal for the fsync tree log was to make it just do the right thing most
>> of the time.  We mostly got there, thanks to a ton of fixes and test cases
>> from Filipe.
>>
>> fsync(some file) -- all the names for this file will exist, without having
>> to fsync the directory.
>>
>> fsync(some dir) -- ugh, don't fsync the directory.  But if you do, all the
>> files/subdirs will exist, and unlinks will be done and renames will be
>> included.  This is slow and may require a full FS commit, which is why we
>> don't want dirs fsunk.
>
> What ext4 does is this:
>
> fsync(some file) -- for a newly created file, the filename that it was
>         created under will exist.  If the file has a hard-link added,
>         the hard link is not guarnateed to be written to disk
>
> fsync(some dir) -- all changes to file names in thentee directory will
>         exist after the crash.  It does *not* guarantee that any data
>         changes to any of files in the directories will persist after
>         a crash.
>
> It seems to me that it would be desirable if all of the major file
> systems have roughly the same minimum guarantee for fsync(2), so that
> application writers don't have to make file-system specific
> assumptions.  In general the goal ought to be "the right thing" should
> happen.
>
> The reason why ext4 doesn't sync all possible hard link names is that
> (a) that's not a common requiremnt for most applications, and (b) it's
> too hard to find all of the directories which might contain a hard
> link to a particular file.  But otherwise, the semantics seem to
> largely match up with what Chris as suggested for btrfs.
>
>                                     - Ted