xfs_check

xfs_check

[Christoph Hellwig]

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?

Re: xfs_check

[Eric Sandeen]

Christoph Hellwig wrote:
> 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?
> 
> 

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

Re: xfs_check

[Chris Wedgwood]

On Tue, May 27, 2008 at 11:48:28AM -0500, Eric Sandeen wrote:

> xfs_check checks... $SOMETHING that xfs_repair still does not, I
> think?

does that imply that that if $SOMETHING is bad it won't be seen then
repaired then?

Re: xfs_check

[Eric Sandeen]

Chris Wedgwood wrote:
> On Tue, May 27, 2008 at 11:48:28AM -0500, Eric Sandeen wrote:
> 
>> xfs_check checks... $SOMETHING that xfs_repair still 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

Re: xfs_check

[Barry Naujok]

On Wed, 28 May 2008 02:55:24 +1000, Eric Sandeen <sandeen@sandeen.net>  
wrote:

> Chris Wedgwood wrote:
>> On Tue, May 27, 2008 at 11:48:28AM -0500, Eric Sandeen wrote:
>>
>>> xfs_check checks... $SOMETHING that xfs_repair still 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.

Re: xfs_check

[Dave Chinner]

On Tue, May 27, 2008 at 06:26:05PM +0200, Christoph Hellwig wrote:
> 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?

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.
-- 
Dave Chinner
david@fromorbit.com

Re: xfs_check

[Barry Naujok]

On Wed, 28 May 2008 02:26:05 +1000, Christoph Hellwig <hch@lst.de> wrote:

> 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?

It's on my "todo" list! Some stuff called case-insensitive support is
delaying work like that :)

Re: xfs_check

[Emmanuel Florac]

Le Tue, 27 May 2008 18:26:05 +0200 vous écriviez:

>  Is there any reason
> why we shouldn't simply kill xfs_check and replaced it with a wrapper
> around xfs_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 :)

-- 
--------------------------------------------------
Emmanuel Florac               www.intellique.com   
--------------------------------------------------