Strange sync/fsync behavior in btrfs

Strange sync/fsync behavior in btrfs

[Arvind Raghavan]

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. However, if we replace (1)
with "fsync B/foo", then upon recovery the link persists. This
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".
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

Re: Strange sync/fsync behavior in btrfs

[Filipe Manana]

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.”