[PATCH] xfstests: fsck scratch device if it got used

[PATCH] xfstests: fsck scratch device if it got used

[Eric Sandeen]

This will cause the $SCRATCH_DEV to be fscked if it
was used in the prior test.  Without this I don't
think it gets done unless specifically requested
by the test.

Also recreate lost+found/ in one test so that e2fsck
doesn't complain.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
---

diff --git a/check b/check
index a4af0f6..343735a 100755
--- a/check
+++ b/check
@@ -308,6 +308,9 @@ do
 	try="$try $seq"
 	n_try=`expr $n_try + 1`
         _check_test_fs
+	if grep -q require_scratch $seq; then
+		_check_scratch_fs
+	fi
     fi
     
     seq="after_$seq"


diff --git a/062 b/062
index 9800e33..b727243 100755
--- a/062
+++ b/062
@@ -216,6 +216,9 @@ if [ $? -ne 0 ]; then
 	exit
 fi
 
+# So e2fsck won't complain:
+[[ $FSTYP = ext* ]] && mkdir $SCRATCH_MNT/lost+found
+
 # success, all done
 status=0
 exit


_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [PATCH] xfstests: fsck scratch device if it got used

[Christoph Hellwig]

On Thu, Nov 29, 2012 at 12:59:55PM -0600, Eric Sandeen wrote:
> This will cause the $SCRATCH_DEV to be fscked if it
> was used in the prior test.  Without this I don't
> think it gets done unless specifically requested
> by the test.

This one looks good.

> Also recreate lost+found/ in one test so that e2fsck
> doesn't complain.

This one I can't make any sense of.  Care to send it separately with a
good explanation?

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [PATCH] xfstests: fsck scratch device if it got used

[Eric Sandeen]

On 11/30/12 10:06 AM, Christoph Hellwig wrote:
> On Thu, Nov 29, 2012 at 12:59:55PM -0600, Eric Sandeen wrote:
>> This will cause the $SCRATCH_DEV to be fscked if it
>> was used in the prior test.  Without this I don't
>> think it gets done unless specifically requested
>> by the test.
> 
> This one looks good.

Hm now that I think of it perhaps I should remove the explicit _check_scratch-es if they happen at the end of the run, just to try to speed things up.

>> Also recreate lost+found/ in one test so that e2fsck
>> doesn't complain.
> 
> This one I can't make any sense of.  Care to send it separately with a
> good explanation?
> 

Ok, sure.

Basically, test does an rm -rf of the scrach mnt, but e2fsck thinks that a missing lost+found/ is cause for complaint and a failure exit code, which then stops the tests :(

(hum, now that I think about it, maybe a broken scratch device shouldn't stop the test series, but should just log a test failure?  What do you think?)

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [PATCH] xfstests: fsck scratch device if it got used

[Dave Chinner]

On Fri, Nov 30, 2012 at 10:08:46AM -0600, Eric Sandeen wrote:
> On 11/30/12 10:06 AM, Christoph Hellwig wrote:
> > On Thu, Nov 29, 2012 at 12:59:55PM -0600, Eric Sandeen wrote:
> >> This will cause the $SCRATCH_DEV to be fscked if it was used in
> >> the prior test.  Without this I don't think it gets done unless
> >> specifically requested by the test.
> > 
> > This one looks good.
> 
> Hm now that I think of it perhaps I should remove the explicit
> _check_scratch-es if they happen at the end of the run, just to
> try to speed things up.

*nod*

> >> Also recreate lost+found/ in one test so that e2fsck doesn't
> >> complain.
> > 
> > This one I can't make any sense of.  Care to send it separately
> > with a good explanation?
> > 
> 
> Ok, sure.
> 
> Basically, test does an rm -rf of the scrach mnt, but e2fsck
> thinks that a missing lost+found/ is cause for complaint and a
> failure exit code, which then stops the tests :(

Shouldn't e2fsck be fixed? i.e. if you have a corrupted filesystem
and it's missing lost+found, how are you expected to create it? by
mounting your corrupted filesystem and modifying it and potentially
making the corruption worse?

> (hum, now that I think about it, maybe a broken scratch device
> shouldn't stop the test series, but should just log a test
> failure?  What do you think?)

Stop it - we should be leaving a corpse that we can dissect to find
out what went wrong. For a corrupted scratch filesystem, running
another test will eat the slowly rotting corpse and leave nothing
useful behind for diagnosing the failure...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [PATCH] xfstests: fsck scratch device if it got used

[Eric Sandeen]

On 11/30/12 4:27 PM, Dave Chinner wrote:
> On Fri, Nov 30, 2012 at 10:08:46AM -0600, Eric Sandeen wrote:
>> On 11/30/12 10:06 AM, Christoph Hellwig wrote:
>>> On Thu, Nov 29, 2012 at 12:59:55PM -0600, Eric Sandeen wrote:
>>>> This will cause the $SCRATCH_DEV to be fscked if it was used in
>>>> the prior test.  Without this I don't think it gets done unless
>>>> specifically requested by the test.
>>>
>>> This one looks good.
>>
>> Hm now that I think of it perhaps I should remove the explicit
>> _check_scratch-es if they happen at the end of the run, just to
>> try to speed things up.
> 
> *nod*

I'll send as another patch; I don't think there are really very
many TBH.

>>>> Also recreate lost+found/ in one test so that e2fsck doesn't
>>>> complain.
>>>
>>> This one I can't make any sense of.  Care to send it separately
>>> with a good explanation?
>>>
>>
>> Ok, sure.
>>
>> Basically, test does an rm -rf of the scrach mnt, but e2fsck
>> thinks that a missing lost+found/ is cause for complaint and a
>> failure exit code, which then stops the tests :(
> 
> Shouldn't e2fsck be fixed? i.e. if you have a corrupted filesystem
> and it's missing lost+found, how are you expected to create it? by
> mounting your corrupted filesystem and modifying it and potentially
> making the corruption worse?

No, e2fsck fixes it, but reports that as an exit error condition
even if nothing else is found.

>> (hum, now that I think about it, maybe a broken scratch device
>> shouldn't stop the test series, but should just log a test
>> failure?  What do you think?)
> 
> Stop it - we should be leaving a corpse that we can dissect to find
> out what went wrong. For a corrupted scratch filesystem, running
> another test will eat the slowly rotting corpse and leave nothing
> useful behind for diagnosing the failure...

True, in most cases you could re-run the test, but maybe not.
Ok, will leave that as-is.

-Eric

> Cheers,
> 
> Dave.
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [PATCH] xfstests: fsck scratch device if it got used

[Carlos Maiolino]

> >>> This one looks good.
> >>
> >> Hm now that I think of it perhaps I should remove the explicit
> >> _check_scratch-es if they happen at the end of the run, just to
> >> try to speed things up.
> > 
> > *nod*
> 
> I'll send as another patch; I don't think there are really very
> many TBH.
> 
> >>>> Also recreate lost+found/ in one test so that e2fsck doesn't
> >>>> complain.
> >>>
> >>> This one I can't make any sense of.  Care to send it separately
> >>> with a good explanation?
> >>>
> >>
> >> Ok, sure.
> >>
> >> Basically, test does an rm -rf of the scrach mnt, but e2fsck
> >> thinks that a missing lost+found/ is cause for complaint and a
> >> failure exit code, which then stops the tests :(
> > 
> > Shouldn't e2fsck be fixed? i.e. if you have a corrupted filesystem
> > and it's missing lost+found, how are you expected to create it? by
> > mounting your corrupted filesystem and modifying it and potentially
> > making the corruption worse?
> 
> No, e2fsck fixes it, but reports that as an exit error condition
> even if nothing else is found.
> 

I know lots of users who use to just delete lost+found directory, so making the
lack of l+f an error is wrong.
IMHO, there is no reason to report an error when a l+f is not found, unless you
need to recover orphan'ed inodes, I've never seen any other usage for it, unless
during FS recovery time. (maybe I lack some knowledge of another usages for
lost+found directory?)

So, I believe that might be useful to print a warning about it, but consider it
as an error is wrong IMHO.

-- 
Carlos

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [PATCH] xfstests: fsck scratch device if it got used

[Eric Sandeen]

On 12/3/12 8:03 AM, Carlos Maiolino wrote:
>>>>> This one looks good.
>>>>
>>>> Hm now that I think of it perhaps I should remove the explicit
>>>> _check_scratch-es if they happen at the end of the run, just to
>>>> try to speed things up.
>>>
>>> *nod*
>>
>> I'll send as another patch; I don't think there are really very
>> many TBH.
>>
>>>>>> Also recreate lost+found/ in one test so that e2fsck doesn't
>>>>>> complain.
>>>>>
>>>>> This one I can't make any sense of.  Care to send it separately
>>>>> with a good explanation?
>>>>>
>>>>
>>>> Ok, sure.
>>>>
>>>> Basically, test does an rm -rf of the scrach mnt, but e2fsck
>>>> thinks that a missing lost+found/ is cause for complaint and a
>>>> failure exit code, which then stops the tests :(
>>>
>>> Shouldn't e2fsck be fixed? i.e. if you have a corrupted filesystem
>>> and it's missing lost+found, how are you expected to create it? by
>>> mounting your corrupted filesystem and modifying it and potentially
>>> making the corruption worse?
>>
>> No, e2fsck fixes it, but reports that as an exit error condition
>> even if nothing else is found.
>>
> 
> I know lots of users who use to just delete lost+found directory, so making the
> lack of l+f an error is wrong.
> IMHO, there is no reason to report an error when a l+f is not found, unless you
> need to recover orphan'ed inodes, I've never seen any other usage for it, unless
> during FS recovery time. (maybe I lack some knowledge of another usages for
> lost+found directory?)
> 
> So, I believe that might be useful to print a warning about it, but consider it
> as an error is wrong IMHO.

I agree, maybe we can change that in e2fsck, and not bother creating it
unless some other error means we need it.

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs