Re: Strange sync/fsync behavior in btrfs

[Filipe Manana <fdmanana@gmail.com>]

On Mon, Apr 6, 2020 at 8:47 PM Arvind Raghavan
<raghavan.arvind@gmail.com> wrote:
>
> Hi!
>
> I am Arvind Raghavan, an undergraduate student at the Unversity
> of Texas at Austin, working with Prof. Vijay Chidambaram. I've
> been working on the Crashmonkey [1] project, which is a test
> harness for file system crash consistency checks. Specifically,
> we've been working on making a fuzzer to find new bugs, and we
> discovered some weird behavior. Given the following workload:
>
> mkdir A
> mkdir B
> mkdir A/C
> creat B/foo
> sync (1)
> link B/foo A/C/foo
> fsync A (2)
> <crash>
>
> Running on Linux 5.5.2, upon recovering the filesystem, the hard
> linked file A/C/foo is not present.

Expected on btrfs at least. Nothing changed in directory A after the
'sync', so the fsync is a noop. Only directory C and the inode of file
B/foo had changes.
We don't go recursively checking if any sub-directories changed. That
would be very expensive, plus I don't think anyone expects that in
real use cases.
If you want A/C/foo persisted then fsync A/C or fsync AC/foo or fsync
B/foo (at least on btrfs this should work).

> However, if we replace (1)
> with "fsync B/foo", then upon recovery the link persists. This

Replacing the 'sync' with 'fsync B/foo' is different.
When that fsync is done the inode is logged in btrfs, and then the
"link B/foo A/C/foo" causes the log to be updated with the new dentry
because the inode was logged before.
It's the link creation that persist the new dentry, not the "fsync A".

> behavior seems strange, as intuitively it seems that sync should
> have at least as strong effect as fsync. In addition, it seems
> that Chris Mason's definition of fsync guarantees here [2] might
> require this workload to pass.
>
> It is important to note that even if we skip the final fsync (2),
> the result is the same. Thus, the behavior is coming only from
> the syncing operation at line (1). However, we were also curious
> to know whether an fsync of the directory A here (2) should
> persist the file A/C/foo. Chris mentions [2] that an fsync
> of a directory means that "all the files/subdirs will exist".

I don't think his definition includes recursion... nor that people
usually expect that.
I think he meant the sub-directory C and all other dentries of A will
exist, not that dentries of C or any other descendants will be
persisted.

Thanks.

> Should this apply to files created in subdirectories?
>
>
> Thanks!
> Arvind
>
> [1] https://www.github.com/utsaslab/crashmonkey
> [2] https://www.spinics.net/lists/linux-btrfs/msg77330.html



-- 
Filipe David Manana,

“Whether you think you can, or you think you can't — you're right.”