On Fri, 2002-10-04 at 03:41, Sidik Isani wrote:
> Yes. I put the whole thing at:
> 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.