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/? --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
