xfs_check
In the past we had quite a few cases where we told people to run xfs_repair -n instead of xfs_check. I think that makes a lot of sense because xfs_repair -n generally gives output at least as useful as xfs_check if not more so and also is a lot faster. Is there any reason why we shouldn't simply kill xfs_check and replaced it with a wrapper around xfs_repair?
Quoted 8 lines · Christoph Hellwig
In the past we had quite a few cases where we told people to run
xfs_repair-n instead ofxfs_check. I think that makes a lot of sense becausexfs_repair-n generally gives output at least as useful asxfs_checkif not more so and also is a lot faster. Is there any reason why we shouldn't simply killxfs_checkand replaced it with a wrapper aroundxfs_repair?
xfs_check checks... $SOMETHING that xfs_repair still does not, I think?
But, if you can't run it on any fs of reasonable size due to memory piggishness, then... *shrug*
-Eric
Quoted 2 lines · Eric Sandeen
xfs_checkchecks... $SOMETHING thatxfs_repairstill does not, I think?
does that imply that that if $SOMETHING is bad it won't be seen then repaired then?
Quoted 7 lines · Chris Wedgwood
Quoted 2 lines · Eric Sandeen
xfs_checkchecks... $SOMETHING thatxfs_repairstill does not, I think?does that imply that that if $SOMETHING is bad it won't be seen then repaired then?
I can't remember what $SOMETHING is but I bet Barry knows :)
-Eric
Quoted 10 lines · Eric Sandeen
Quoted 7 lines · Chris Wedgwood
Quoted 2 lines · Eric Sandeen
xfs_checkchecks... $SOMETHING thatxfs_repairstill does not, I think?does that imply that that if $SOMETHING is bad it won't be seen then repaired then?
I can't remember what $SOMETHING is but I bet Barry knows :)
Free space btrees!
But I would be enhancing xfs_repair -n to actually check them.
Quoted 6 lines · Christoph Hellwig
In the past we had quite a few cases where we told people to run
xfs_repair-n instead ofxfs_check. I think that makes a lot of sense becausexfs_repair-n generally gives output at least as useful asxfs_checkif not more so and also is a lot faster. Is there any reason why we shouldn't simply killxfs_checkand replaced it with a wrapper aroundxfs_repair?
xfs_repair doesn't yet check free space btrees - it simply blows them away and rebuilds htem from scratch. Hence errors in those btrees will go unreported. xfs_check will tell you about errors in those trees.
Cheers,
Dave.
Signature · 2 lines
Dave Chinner [email protected]
Quoted 6 lines · Christoph Hellwig
In the past we had quite a few cases where we told people to run
xfs_repair-n instead ofxfs_check. I think that makes a lot of sense becausexfs_repair-n generally gives output at least as useful asxfs_checkif not more so and also is a lot faster. Is there any reason why we shouldn't simply killxfs_checkand replaced it with a wrapper aroundxfs_repair?
It's on my "todo" list! Some stuff called case-insensitive support is delaying work like that :)
Le Tue, 27 May 2008 18:26:05 +0200 vous écriviez:
Quoted 3 lines
Is there any reason
why we shouldn't simply killxfs_checkand replaced it with a wrapper aroundxfs_repair?
I may add that I hardly even had any filesystem recently small enough to fit xfs_check hunger for memory. All attempts to use xfs_check invariably ended with "out of memory" for 5 years or more. Actually IIRC I used xfs_check succesfully only on IRIX, back in the time of 9GB usrroot drives :)
Signature · 3 lines
-------------------------------------------------- Emmanuel Florac www.intellique.com --------------------------------------------------