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,
Frank...
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.
Steve
--
--------------------------------------------------------------------------
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
|