[Top] [All Lists]

Re: xfs_check problems on 3.6TB fs

To: Steve Lord <lord@xxxxxxx>
Subject: Re: xfs_check problems on 3.6TB fs
From: Frank Hellmann <frank@xxxxxxxxxxxxx>
Date: Thu, 28 Oct 2004 02:20:14 +0200
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <418007B3.7040207@xxxxxxx>
Organization: Optical Art Film- und Special-Effects GmbH
References: <20041025150037.GA4665@xxxxxxxxxxxxxx> <417E216A.2090503@xxxxxxxxxxxxx> <20041027201339.GA13311@xxxxxxxxxxxxxx> <418007B3.7040207@xxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616
Hi Steve!

I think if anybody can spend some time to "extend" (fix) the way xfs_db/xfs_check and xfs_repair are handling large filesystems under linux, this would be really appreciated. I think 2TB+ filesystems on 2GB system memory will get so common over the next couple of months that this really needs to be adressed. Just my opinion...

I had a look into the xfs_db sources today and I still have no clue what is going on. There has been so much effort put in there (means a lot of code to understand), so maybe somebody with more expirience with the xfs tools can take a look?

        Thanks. Cheers,


Steve Lord wrote:
Michal Szymanski wrote:

Hi Frank,

Thanks for your comments.

The oss.sgi.com/projects/xfs pages content suggests that actually 'fcsk' is not needed anymore on a journalling FS like XFS. So maybe we can just
live without it?

No. There will be times, you'll need it. Powerloss is never going to give you predictable results.

That would support my theory that there is a wrap-around bug somewhere in xfs_check. It is not in xfs_repair. so I'll give it a try and have a look.

Still, if I am correct, 'xfs_check' gives just information on the FS
status and it is 'xfs_repair' that does the real job. So the 'xfs_check'
seems not to be that important.

Michal Szymanski

xfs_check is a wrapper around xfs_db, it does a fairly extensive
metadata consistancy check, but does not fix anything up. xfs_repair
is the tool for fixing things.

I remember cases on Irix were we had to build a special 64 bit
version of the tool (to get a larger address space), and get
the customer to add more swap to succeed in running to completion.

These programs have been put on a diet, but the memory demands of
repairing/checking really large filesystems are still significant.


Frank Hellmann          Optical Art GmbH           Waterloohain 7a
DI Supervisor           http://www.opticalart.de   22769 Hamburg
frank@xxxxxxxxxxxxx     Tel: ++49 40 5111051       Fax: ++49 40 43169199

<Prev in Thread] Current Thread [Next in Thread>