Re: [PATCH v2] generic: test i_mode recovery after power failure

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]



On 2019/3/6 4:53, Dave Chinner wrote:
> On Tue, Mar 05, 2019 at 07:47:44PM +0800, Chao Yu wrote:
>> After fsync, filesystem should guarantee inode metadata including
>> permission info being persisted, so even after sudden power-cut,
>> during mount, we should recover i_mode fields correctly, in order
>> to not loss those meta info.
>>
>> So adding this testcase to check whether generic filesystem can
>> guarantee that.
> 
> Can I make a suggestion here?
> 
> I've noticed that we are getting a lot of these one-off, random
> "fsync persists one specific piece of metadata in one specific case"
> tests, mainly in response to some fsync bug that was found in btrfs.
> This is reactive, and does not find new bugs in this area.
> 
> We are also beyond the point where the number of tests is
> maintainable (e.g. to be able to make infrastructure changes), so we
> really should be looking to consolidate largely similar tests into
> single tests where possible.
> 
> I'd strongly suggest that a robust fsync tester should be written
> for all the cases that are currently being addressed in an ad hoc
> fashion. Then they can be consolidated into a single test run, and
> we can get rid of all the one-off "fsync failed on this <specific
> thing>" tests from the harness.

Thanks for the suggestion, and that makes sense.

> 
> Oh, wait, we *already have that infrastructure*: src/fsync-tester.c
> and generic/311.
> 
> Can we please consider rolling all of these "do something, fsync,
> drop-writes, remount check" into fsync-tester.c and do the same for
> all future one-off "did fsync persist X" tests?

Let me add this testcase into fsync-tester.c, still we need add new
testcase in generic/ directory instead of changing generic/311 directly,
right? since as I remember that Eryu mentioned that:

"Usually we don't add new sub-tests to existing tests, so new failures
introduced by the new sub-tests won't be treated as false regressions.
Please add a new test instead."

https://patchwork.kernel.org/patch/10042149/

Or to avoid redundant copied code from generic/311 in each fsync related
patch, do I need just add my case into fsync_tester.c? and before
announcement of fstests master branch, we can add one testcase into
generic/ directory, in that testcase we gather/test all new added cases in
fsync_tester.c recently.

Which one is easier for you to maintain?

Thanks,

> 
> Cheers,
> 
> Dave.
> 




[Index of Archives]     [Linux Filesystems Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux