Hi, A gentle reminder on the crash consistency bug that we found on btrfs: Link count of a file is not persisted even after a fsync. We believe a filesystem that ensures strictly ordered metadata behaviour should be able to persist the hard link after a fsync on the original file. Could you comment on why btrfs does not exhibit this behavior, and if it's something you'd want to fix?
Thanks, Jayashree Mohan On Mon, Apr 16, 2018 at 9:35 AM, Jayashree Mohan <jayashree2...@gmail.com> wrote: > Hi, > > The following seems to be a crash consistency bug on btrfs, where in > the link count is not persisted even after a fsync on the original > file. > > Consider the following workload : > creat foo > link (foo, A/bar) > fsync(foo) > ---Crash--- > > Now, on recovery we expect the metadata of foo to be persisted i.e > have a link count of 2. However in btrfs, the link count is 1 and file > A/bar is not persisted. The expected behaviour would be to persist the > dependencies of inode foo. That is to say, shouldn't fsync of foo > persist A/bar and correctly update the link count? > Note that ext4, xfs and f2fs recover to the correct link count of 2 > for the above workload. > > Let us know what you think about this behavior. > > Thanks, > Jayashree Mohan -- 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
