Re: [PATCH 1/2] fstests: generic test for directory fsync after rename operation

[Filipe Manana <fdmanana@kernel.org>]

On Thu, Feb 18, 2016 at 1:30 AM, Dave Chinner <david@fromorbit.com> wrote:
> On Mon, Feb 15, 2016 at 10:54:23AM +0000, fdmanana@kernel.org wrote:
>> From: Filipe Manana <fdmanana@suse.com>
>>
>> Test that if we move one file between directories, fsync the parent
>> directory of the old directory, power fail and remount the filesystem,
>> the file is not lost and it's located at the destination directory.
>>
>> This is motivated by a bug found in btrfs, which is fixed by the patch
>> (for the linux kernel) titled:
>>
>>   "Btrfs: fix file loss on log replay after renaming a file and fsync"
>>
>> Tested against ext3, ext4, xfs, f2fs and reiserfs.
>>
>> Signed-off-by: Filipe Manana <fdmanana@suse.com>
> ....
>> +# We expect our file foo to exist, have an entry in the new parent
>> +# directory (c/) and not have anymore an entry in the old parent directory
>> +# (a/b/).
>> +[ -e $SCRATCH_MNT/a/b/foo ] && echo "File foo is still at directory a/b/"
>> +[ -e $SCRATCH_MNT/c/foo ] || echo "File foo is not at directory c/"
>> +
>> +# The new file named bar should also exist.
>> +[ -e $SCRATCH_MNT/a/bar ] || echo "File bar is missing"
>
> This can all be replaced simply by:
>
> ls -R $SCRATCH_MNT | _filter_scratch
>
> Because the golden image match will tell us if files are missing or
> in the wrong place.

The problem with that is ext3/4 have the lost+found directory that
xfs, btrfs, etc don't have.
Do you mind about something like this:

# exclude lost+found directory specific to some filesystems (ext3/4)
ls -R $SCRATCH_MNT | grep -v 'lost+found' | tr -s '\n' | _filter_scratch

(since you usually dislike generic tests having any specific logic for
specific filesystems)

Also do I need to remove _need_to_be_root for the 3 tests I submitted?
I only noticed there was a submitted patch that kills that function
after sending them.

thanks


>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com