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 following seems to be a crash consi
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)
> fsyn
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 for fsync (foo) is persiste
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 commen
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.