Directory entry not persisted on a fsync

Directory entry not persisted on a fsync

[Jayashree Mohan]

Hi,

We came across a scenario where inspite of fsync-ing the directory,
the entry was not persisted - the file created under this directory
was lost.

Consider the following workload :

1. creat test/foo
2. mkdir test/A
3. creat test/A/foo
4. fsync test/A/foo
5. fsync test
-----crash-----

When we recover after the crash, the contents in the directory are as follows:
dir test:
    A

dir test/A:
    foo

Notice that file foo that was created in step 1 above, is lost inspite
of calling a fsync on its parent directory. On all other
filesystems(ext4, xfs, and f2fs), we see file foo persisted in the
test directory. We expect directory entries to be persisted when the
directory inode is fsynced right? Losing file foo doesn't seem to be
the right behavior.


Thanks,
Jayashree Mohan

Re: Directory entry not persisted on a fsync

[Jayashree Mohan]

Hi,

A gentle reminder on the above behavior on btrfs : Even on fsync-ing
the directory, its entries are not persisted. Could you let us know
your thoughts on this?

Thanks,
Jayashree Mohan



On Fri, Apr 20, 2018 at 1:05 PM, Jayashree Mohan
<jayashree2912@gmail.com> wrote:
> Hi,
>
> We came across a scenario where inspite of fsync-ing the directory,
> the entry was not persisted - the file created under this directory
> was lost.
>
> Consider the following workload :
>
> 1. creat test/foo
> 2. mkdir test/A
> 3. creat test/A/foo
> 4. fsync test/A/foo
> 5. fsync test
> -----crash-----
>
> When we recover after the crash, the contents in the directory are as follows:
> dir test:
>     A
>
> dir test/A:
>     foo
>
> Notice that file foo that was created in step 1 above, is lost inspite
> of calling a fsync on its parent directory. On all other
> filesystems(ext4, xfs, and f2fs), we see file foo persisted in the
> test directory. We expect directory entries to be persisted when the
> directory inode is fsynced right? Losing file foo doesn't seem to be
> the right behavior.
>
>
> Thanks,
> Jayashree Mohan

Re: Directory entry not persisted on a fsync

[David Sterba]

On Sat, Apr 21, 2018 at 12:23:58PM -0500, Jayashree Mohan wrote:
> A gentle reminder on the above behavior on btrfs : Even on fsync-ing
> the directory, its entries are not persisted. Could you let us know
> your thoughts on this?

Sending a gentle reminder one day after the report and even on a weekend
day will not make any difference, please avoid that in the future.

Re: Directory entry not persisted on a fsync

[Vijay Chidambaram]

Hi all,

Any thoughts on this?

We completely understand you are all busy and might be traveling, so
we only need a simple ack from you: that when we fsync a directory in
btrfs, we can expect the contents to get persisted. We understand that
is not your highest priority item, and that you will fix it later.

The reason we email to the list is because there is no written set of
guarantees each file system provides. So working with the file-system
developers is the only way we can understand whether something is
intentional behavior or a bug.

It would help us investigate btrfs crash consistency better in the
future and possibly help us find bugs!

Thanks,
Vijay

On Fri, Apr 20, 2018 at 1:05 PM, Jayashree Mohan
<jayashree2912@gmail.com> wrote:
>
> Hi,
>
> We came across a scenario where inspite of fsync-ing the directory,
> the entry was not persisted - the file created under this directory
> was lost.
>
> Consider the following workload :
>
> 1. creat test/foo
> 2. mkdir test/A
> 3. creat test/A/foo
> 4. fsync test/A/foo
> 5. fsync test
> -----crash-----
>
> When we recover after the crash, the contents in the directory are as follows:
> dir test:
>     A
>
> dir test/A:
>     foo
>
> Notice that file foo that was created in step 1 above, is lost inspite
> of calling a fsync on its parent directory. On all other
> filesystems(ext4, xfs, and f2fs), we see file foo persisted in the
> test directory. We expect directory entries to be persisted when the
> directory inode is fsynced right? Losing file foo doesn't seem to be
> the right behavior.
>
>
> Thanks,
> Jayashree Mohan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html