[Top] [All Lists]

Re: unable to use xfs_repair

To: Sidik Isani <lksi@xxxxxxxxxxxxxxx>
Subject: Re: unable to use xfs_repair
From: Stephen Lord <lord@xxxxxxx>
Date: 04 Oct 2002 07:06:00 -0500
Cc: Seth Mos <knuffie@xxxxxxxxx>, linux-xfs@xxxxxxxxxxx
In-reply-to: <20021003224118.A12588@cfht.hawaii.edu>
References: <20021003170436.A11748@cfht.hawaii.edu> <> <20021003224118.A12588@cfht.hawaii.edu>
Sender: linux-xfs-bounce@xxxxxxxxxxx
On Fri, 2002-10-04 at 03:41, Sidik Isani wrote:
>   Yes.  I put the whole thing at:
> http://software.cfht.hawaii.edu/xfs_repair.strace.gz
>   Memory usage actually jumped to almost 800 MB right away and stayed
>   there for a while.  Then it went back under 10 MB, and then to 30
>   for a while before exiting.
> > >   I picked up a recent version of xfs_repair (2.3.3 that I got out of
> > >   CVS a few days ago) and it consumes all of 1 GB and never finishes
> > >   repairing.  I can't add more swap space in a *file*, so ... well,
> > >   this is a bit awkward.  Is it normal for xfs_repair to consume that
> > >   much memory, and can anything be done about it?  Is there something
> > >   strange about my filesystem causing xfs_repair to leak possibly?
> > 
> > There have been multiple fixes in both the recovery part and the xfs_repair 
> > utility and their memory usage. I have never seen this happen before.
> > 
> > The other developers might be able to understand a strace.
> > 
> > >   Ok, I scrounged some other partitions and converted them into swap,
> > >   but if this is normal I guess we should consider splitting in the
> > >   future to avoid grid-lock.  Don't make an FS that > 1000 times
> > >   available RAM?  Seems nicer if we can avoid that, what do you think
> > >   the practical limitations are?
> > 
> > There are a number of users out there with really large partitions that 
> > don't see it. How much ram does the machine actually have?
>   1 GB.  I added another 1.8 GB of swap, and then xfs_repair was
>   completed in a reasonable amount of time.  We know not to partition
>   less than .1% of the disk as swap now.  That's not such a sacrifice,
>   and xfs_repair is happy.  There may be good reasons it needs to
>   grab 800 MB... it's a pretty huge filesystem.  I just wanted to
>   make sure?
> Be seeing you,
> - Sidik

repair does have a map of the blocks in the filesystem, we have had
cases with multi-terabyte filesystems where we had to build a special
binary on irix. We now ship this by default there. Unfortunately the
reason for the special binary was to switch to a binary format
which allows a larger address space. There are some ideas floating
around about how to reduce this memory usage - looks like it is
time to look harder at them.


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