On Thu, Feb 18, 2016 at 4:43 PM, Darrick J. Wong
<darrick.w...@oracle.com> wrote:
> On Thu, Feb 18, 2016 at 01:38:41PM +0000, Filipe Manana wrote:
>> On Thu, Feb 18, 2016 at 1:30 AM, Dave Chinner <da...@fromorbit.com> wrote:
>> > On Mon, Feb 15, 2016 at 10:54:23AM +0000, fdman...@kernel.org wrote:
>> >> From: Filipe Manana <fdman...@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 <fdman...@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.
>
> XFS can have lost+found too, though this seems unlikely on the scratch mount.
>
>> 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
>
> Why not put "a" and "c" under $SCRATCH_MNT/test-335/?

Would work as well. I was thinking earlier of just doing two ls -R
calls, one for a/ and other for c/.
Thanks Darrick.

>
> --D
>
>>
>> (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
>> > da...@fromorbit.com
>> --
>> To unsubscribe from this list: send the line "unsubscribe fstests" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to