xfstests: fsck scratch device if it got used
PATCH 1/1 xfstests: fsck scratch device if it got used
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.
---
check +3 -0
@@ -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"
062 +3 -0
@@ -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
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 4 lines · 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.
This one looks good.
Quoted 2 lines
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
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 7 lines · Christoph Hellwig
Quoted 4 lines · 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.
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.
Quoted 6 lines
Quoted 2 lines
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
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 11 lines · Eric Sandeen
Quoted 6 lines · Christoph Hellwig
Quoted 3 lines · 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.
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*
Quoted 7 lines
Quoted 6 lines
Quoted 2 lines
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?
Quoted 5 lines
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?
Quoted 3 lines
(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.
Signature · 7 lines
Dave Chinner [email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 7 lines · Dave Chinner
Quoted 6 lines · Eric Sandeen
Quoted 5 lines · Christoph Hellwig
Quoted 3 lines · 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.
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
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.
Quoted 9 lines
Quoted 9 lines
Quoted 6 lines
Quoted 2 lines
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.
Quoted 8 lines
Quoted 3 lines
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.
Quoted 8 lines
Quoted 3 lines
(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
Quoted 4 lines
Cheers,
Dave.
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 24 lines
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
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.
Quoted 13 lines
Quoted 12 lines
Quoted 6 lines
Quoted 2 lines
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 :(
Quoted 8 lines
Quoted 4 lines
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.
Signature · 6 lines
Carlos _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 40 lines · Carlos Maiolino
Quoted 24 lines
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
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.
Quoted 13 lines
Quoted 12 lines
Quoted 6 lines
Quoted 2 lines
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 :(
Quoted 8 lines
Quoted 4 lines
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?)
Quoted 2 lines
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
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs