Hi Amir,

Thanks for the reply!

On Fri, Apr 13, 2018 at 12:52 AM, Amir Goldstein <amir7...@gmail.com> wrote:
> Not a bug.
> From man 2 fsync:
> "Calling  fsync() does not necessarily ensure that the entry in the
>  directory containing the file has also reached disk.  For that an
>  explicit fsync() on a file descriptor for the directory is also needed."

Are we understanding this right:

ext4 and xfs fsync the parent directory if a sym link file is
fsync-ed. But btrfs does not. Is this what we are seeing?

I agree that fsync of a file does not mean fsync of its directory
entry, but it seems odd to do it for regular files and not for sym
links. We do not see this behavior if we use a regular file instead of
a sym link file.

> There is a reason why this behavior is not being reproduces in
> ext4/xfs, but you should be able to reproduce a similar issue
> like this:
> 1. symlink (foo, bar.tmp)
> 2. open bar.tmp
> 3. fsync bar.tmp
> 4. rename(bar.tmp, bar)
> 5. fsync bar
> ----crash here----

I'm guessing xfs/ext4 detect the symlink-fsync pattern and fsync the
parent dir in our workload, but would miss it because of the rename in
the workload you provided?

Vijay Chidambaram
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to