On 2022/3/9 14:22, Dave Chinner wrote:
On Wed, Mar 09, 2022 at 12:31:17PM +0800, Chao Yu wrote:
On 2022/2/28 11:57, Sun Ke via Linux-f2fs-devel wrote:
The test fail on f2fs:
xattr names and values after second fsync log replay:
# file: SCRATCH_MNT/foobar
+user.attr1="val1"
user.attr3="val3"
attr1 is still there after log replay.
I guess it is f2fs's special feature to improve the performance.
Signed-off-by: Sun Ke <sunke32@xxxxxxxxxx>
---
Is it a BUG on f2fs?
I don't think so, it fails due to f2fs doesn't follow recovery rule which
btrfs/ext4/xfs does, but it doesn't mean f2fs has break posix semantics of
fsync().
I disagree. A failure in this test is indicative of non-conformance
with the Linux definition of fsync() behaviour.
You are right in that it does not break POSIX fsync semantics, but
POSIX allows "do nothing" as a valid implementation. However,
because of this loophole, the POSIX definition is complete garbage
and we do not use it.
That behaviour that Linux filesytsems are supposed to implement is
defined in the Linux fsync() man page, and it goes way beyond what
POSIX requires:
$ man fsync
....
DESCRIPTION
fsync() transfers ("flushes") all modified in-core data of
(i.e., modified buffer cache pages for) the file referred to by
the file descriptor fd to the disk device (or other permanent
storage device) so that all changed information can be retrieved
even if the system crashes or is rebooted. This includes
writing through or flushing a disk cache if present. The call
blocks until the device reports that the transfer has
completed.
As well as flushing the file data, fsync() also flushes the
metadata information associated with the file (see inode(7)).
....
IOWs, fsync() on Linux is supposed to persist all data and
metadata associated with the inode to stable storage such that it
can be retreived after a crash or reboot. "metadata information"
includes xattrs attached to the inode that is being fsync()d.
Quoted from g/066:
echo "hello world!" >> $SCRATCH_MNT/foobar
$XFS_IO_PROG -c "fsync" $SCRATCH_MNT/foobar
$SETFATTR_PROG -x user.attr1 $SCRATCH_MNT/foobar
ln $SCRATCH_MNT/foobar $SCRATCH_MNT/foobar_link
touch $SCRATCH_MNT/qwerty
$XFS_IO_PROG -c "fsync" $SCRATCH_MNT/qwerty
IIUC, to match what Linux fsync() manual restricts, if we want to persist the
xattr removal, we should call fsync() on $SCRATCH_MNT/foobar after
"$SETFATTR_PROG -x user.attr1 $SCRATCH_MNT/foobar"? rather than calling fsync()
on unrelated $SCRATCH_MNT/qwerty.
Thanks,
*fdatasync()* does not require xattrs to be persisted unless
they are needed to retreive data, but that's not what g/066 is
exercising.
Cheers,
Dave.
