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

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



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.

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



[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