Re: Hard link not persisted on fsync

Hi Zygo, Thanks for the reply. Here are few responses about btrfs behavior that you had questions about in your email. On Thu, Apr 19, 2018 at 4:41 PM, Zygo Blaxell wrote: > > On Mon, Apr 16, 2018 at 09:35:24AM -0500, Jayashree Mohan wrote: > > Hi, > > > > The

Re: Hard link not persisted on fsync

On Mon, Apr 16, 2018 at 09:35:24AM -0500, Jayashree Mohan 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) >

Re: Hard link not persisted on fsync

On Wed, Apr 18, 2018 at 1:02 AM, Jayashree Mohan wrote: > Hi, > > A gentle reminder on the crash consistency bug that we found on btrfs: Why do you call it a consistency bug? The filesystem does not stay in inconsistent state. The link count stays 1 and the dentry used

Re: Hard link not persisted on fsync

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

Hard link not persisted on fsync

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