On Wed, Jan 11, 2012 at 12:37:49AM +0800, Eryu Guan wrote:
> fsck.extN will complain lost+found is missing and fail 273.
> So create lost+found explicitly after removing everything in
> $SCRATCH_MNT.
I'd consider that a bug in e2fsck. Other filesystems handle missing
lost+found directories without failing, but then again it's only
these new tests that do this so fixing the tests is probably the
right thing to do here.
> Signed-off-by: Eryu Guan <guaneryu@xxxxxxxxx>
> ---
> 273 | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/273 b/273
> index 2965132..9ecb2d3 100755
> --- a/273
> +++ b/273
> @@ -36,6 +36,7 @@ _cleanup()
> {
> cd /
> rm -rf $SCRATCH_MNT/* $tmp.*
> + mkdir -p $SCRATCH_MNT/lost+found
> _scratch_unmount
> }
We shouldn't be removing files from the scratch device in the
_cleanup function - if the test exits or fails, we need the corpse
to be intact for debugging. Remving $SCRATCH_MNT/* from the rm
command is what should be done here.
>
> @@ -107,6 +108,7 @@ _do_workload()
> _pid=1
>
> rm -rf $SCRATCH_MNT/*
> + mkdir -p $SCRATCH_MNT/lost+found
And rather than doing this, the test should put all it's files in a
known location on the $SCRATCH_MNT and just remove that. e.g:
WORK_DIR="$SCRATCH_MNT/$seq"
....
rm -rf $WORKDIR
....
The same fixes are required for 274 and 275 as well.
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
