On Thu, Feb 18, 2016 at 4:43 PM, Darrick J. Wong <darrick.wong@xxxxxxxxxx> 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 <david@xxxxxxxxxxxxx> wrote: >> > On Mon, Feb 15, 2016 at 10:54:23AM +0000, fdmanana@xxxxxxxxxx wrote: >> >> From: Filipe Manana <fdmanana@xxxxxxxx> >> >> >> >> 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@xxxxxxxx> >> > .... >> >> +# 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 >> > david@xxxxxxxxxxxxx >> -- >> To unsubscribe from this list: send the line "unsubscribe fstests" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
