xfs
[Top] [All Lists]

Re: xfs_check problems on 3.6TB fs

To: Michal Szymanski <msz@xxxxxxxxxxxxxx>
Subject: Re: xfs_check problems on 3.6TB fs
From: Steve Lord <lord@xxxxxxx>
Date: Wed, 27 Oct 2004 15:40:19 -0500
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <20041027201339.GA13311@xxxxxxxxxxxxxx>
References: <20041025150037.GA4665@xxxxxxxxxxxxxx> <417E216A.2090503@xxxxxxxxxxxxx> <20041027201339.GA13311@xxxxxxxxxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mozilla Thunderbird 0.7.1 (X11/20040626)
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


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