diff mbox series

[v2] generic/066: attr1 is still there after log replay on f2fs

Message ID 20220311094315.2476774-1-sunke32@huawei.com (mailing list archive)
State New, archived
Headers show
Series [v2] generic/066: attr1 is still there after log replay on f2fs | expand

Commit Message

Sun Ke March 11, 2022, 9:43 a.m. UTC
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. f2fs doesn't support fs-op level
transaction functionality. so it have no way to persist all metadata
updates in one transaction.  We can use "fastboot" mountoption for this
case, so during last fsync on qwerty, f2fs can trigger a checkpoint
which will persist all metadata updates before fsync().

Suggested-by: Chao Yu <chao@kernel.org>
Signed-off-by: Sun Ke <sunke32@huawei.com>
---
 tests/generic/066 | 8 ++++++++
 1 file changed, 8 insertions(+)

Comments

Chao Yu March 15, 2022, 4:01 a.m. UTC | #1
On 2022/3/11 17:43, 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. f2fs doesn't support fs-op level
> transaction functionality. so it have no way to persist all metadata
> updates in one transaction.  We can use "fastboot" mountoption for this
> case, so during last fsync on qwerty, f2fs can trigger a checkpoint
> which will persist all metadata updates before fsync().
> 
> Suggested-by: Chao Yu <chao@kernel.org>
> Signed-off-by: Sun Ke <sunke32@huawei.com>
> ---
>   tests/generic/066 | 8 ++++++++
>   1 file changed, 8 insertions(+)
> 
> diff --git a/tests/generic/066 b/tests/generic/066
> index 105a7acd..b8465101 100755
> --- a/tests/generic/066
> +++ b/tests/generic/066
> @@ -56,6 +56,14 @@ sync
>   $SETFATTR_PROG -x user.attr2 $SCRATCH_MNT/foobar
>   $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/foobar
>   
> +# f2fs doesn't support fs-op level transaction functionality. so it have no way
> +# to persist all metadata updates in one transaction.  We can use "fastboot"
> +# mountoption for this case, so during last fsync on qwerty, f2fs can trigger a
> +# checkpoint which will persist all metadata updates before fsync().
> +if [ $FSTYP = "f2fs" ]; then
> +	export MOUNT_OPTIONS="-o fastboot"

Can we merge "fastboot" with original mount options? and after the test, how about
recovering to original mount options?

Thanks,

> +fi
> +
>   _flakey_drop_and_remount
>   
>   # After the fsync log is replayed, the file should have only 2 xattrs, the ones
Sun Ke March 15, 2022, 9:34 a.m. UTC | #2
在 2022/3/15 12:01, Chao Yu 写道:
> On 2022/3/11 17:43, 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. f2fs doesn't support fs-op level
>> transaction functionality. so it have no way to persist all metadata
>> updates in one transaction.  We can use "fastboot" mountoption for this
>> case, so during last fsync on qwerty, f2fs can trigger a checkpoint
>> which will persist all metadata updates before fsync().
>>
>> Suggested-by: Chao Yu <chao@kernel.org>
>> Signed-off-by: Sun Ke <sunke32@huawei.com>
>> ---
>>   tests/generic/066 | 8 ++++++++
>>   1 file changed, 8 insertions(+)
>>
>> diff --git a/tests/generic/066 b/tests/generic/066
>> index 105a7acd..b8465101 100755
>> --- a/tests/generic/066
>> +++ b/tests/generic/066
>> @@ -56,6 +56,14 @@ sync
>>   $SETFATTR_PROG -x user.attr2 $SCRATCH_MNT/foobar
>>   $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/foobar
>> +# f2fs doesn't support fs-op level transaction functionality. so it 
>> have no way
>> +# to persist all metadata updates in one transaction.  We can use 
>> "fastboot"
>> +# mountoption for this case, so during last fsync on qwerty, f2fs can 
>> trigger a
>> +# checkpoint which will persist all metadata updates before fsync().
>> +if [ $FSTYP = "f2fs" ]; then
>> +    export MOUNT_OPTIONS="-o fastboot"
> 
> Can we merge "fastboot" with original mount options? and after the test, 
> how about
> recovering to original mount options?
> 
> Thanks,

Like this:

  if [ $FSTYP = "f2fs" ]; then
-       export MOUNT_OPTIONS="-o fastboot"
+       export MOUNT_OPTIONS="-o fastboot $MOUNT_OPTIONS"
  fi

right?

And I have tested that there is no need to recover to original mount 
options after the test. It will be the original one in the next test.

Thanks,
Sun Ke

> 
>> +fi
>> +
>>   _flakey_drop_and_remount
>>   # After the fsync log is replayed, the file should have only 2 
>> xattrs, the ones
> .
diff mbox series

Patch

diff --git a/tests/generic/066 b/tests/generic/066
index 105a7acd..b8465101 100755
--- a/tests/generic/066
+++ b/tests/generic/066
@@ -56,6 +56,14 @@  sync
 $SETFATTR_PROG -x user.attr2 $SCRATCH_MNT/foobar
 $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/foobar
 
+# f2fs doesn't support fs-op level transaction functionality. so it have no way
+# to persist all metadata updates in one transaction.  We can use "fastboot"
+# mountoption for this case, so during last fsync on qwerty, f2fs can trigger a
+# checkpoint which will persist all metadata updates before fsync().
+if [ $FSTYP = "f2fs" ]; then
+	export MOUNT_OPTIONS="-o fastboot"
+fi
+
 _flakey_drop_and_remount
 
 # After the fsync log is replayed, the file should have only 2 xattrs, the ones