Re: [PATCH] generic: add test for fsync after shrinking truncate and rename

From: Dave Chinner <david@fromorbit.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Filipe Manana <fdmanana@kernel.org>,
	fstests <fstests@vger.kernel.org>,
	Linux Btrfs <linux-btrfs@vger.kernel.org>,
	Filipe Manana <fdmanana@suse.com>
Subject: Re: [PATCH] generic: add test for fsync after shrinking truncate and rename
Date: Thu, 7 Mar 2019 08:48:13 +1100	[thread overview]
Message-ID: <20190306214813.GE26298@dastard> (raw)
In-Reply-To: <CAOQ4uxggon==2r2hibMvXc4_N4zod+2z0Ycw74eKRn+q1uwYsw@mail.gmail.com>

On Wed, Mar 06, 2019 at 09:51:23AM +0200, Amir Goldstein wrote:
> On Wed, Mar 6, 2019 at 12:33 AM Dave Chinner <david@fromorbit.com> wrote:
> > > So the reason this is working is because 2nd fsync needs to
> > > persist ctime of B and not because it needs to persist the
> > > truncate.
> >
> > ctime modifications during rename are irrelevent because there's no
> > fsync between the truncate and the rename so the file inode is
> > already dirty due to the truncate. I think you've got the wrong end
> > of the stick here, Amir. :)
> 
> Doh! The discussion is still interesting because people have
> hard time to understand that those hidden details like ctime
> update on rename may have different behavior on different fs
> regardless if they obay ordered metadata or not.
> Btrfs is different in the respect of metadata dependencies from
> xfs/ext4 in many ways as seen in the different rename/link
> crash consistency discussions.

Yes, little things like can result in different behaviour, but what
we are trying to do is get to the point where there is minimal
difference between all crash-recovery-capable linux filesystems.

e.g. what we see here is that by always including the inode being
moved in the rename transaction (regardless of how a filesystem
acheives that), we provide consistent, reliable, predictable
behaviour in all cases of "fsync after rename". IOWs, the SOMC model
that _require_metadata_journaling tests are supposed to conform to
is far more strict that POSIX requires and our tests need to reflect
this stricter consistency model.

IOWs, we should be encoding the behaviour we want in these tests
rather than implementing yet another "test POSIX compatible
behaviour" - POSIX is a complete crapshoot when it comes to
persistence requirements. And if a filesystem fails a SOMC-model
test, then the filesystem needs to be fixed, not have the test
"relaxed" to only exercise POSIX-defined behaviour.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com