| To: | Steve Lord <lord@xxxxxxx> |
|---|---|
| Subject: | Re: unable to use xfs_repair |
| From: | Andi Kleen <ak@xxxxxxx> |
| Date: | Fri, 4 Oct 2002 18:55:04 +0200 |
| Cc: | Andi Kleen <ak@xxxxxxx>, Sidik Isani <lksi@xxxxxxxxxxxxxxx>, linux-xfs@xxxxxxxxxxx |
| In-reply-to: | <1033749897.6896.20.camel@xxxxxxxxxxxxxxxxxxxx> |
| References: | <20021003170436.A11748@xxxxxxxxxxxxxxx> <4.3.2.7.2.20021004090036.036b5728@xxxxxxxxxxxxx> <20021003224118.A12588@xxxxxxxxxxxxxxx> <1033747014.2457.11.camel@xxxxxxxxxxxxxxxxxxxx> <20021004182151.A8443@xxxxxxxxxxxxx> <1033749897.6896.20.camel@xxxxxxxxxxxxxxxxxxxx> |
| Sender: | linux-xfs-bounce@xxxxxxxxxxx |
| User-agent: | Mutt/1.3.22.1i |
On Fri, Oct 04, 2002 at 11:44:57AM -0500, Steve Lord wrote: > On Fri, 2002-10-04 at 11:21, Andi Kleen wrote: > > > OK, I went and had a look, and we are actually as efficient as we can > > > be in use of the memory itself. Only problem is that we allocate 4 times > > > what we use. I fixed this in cvs. > > > > Unless you memset it (=actually using, not allocating) and it still > > fits into the 32big address space that could be worked around by > > echo 1 > /proc/sys/vm/overcommit_memory > > It uses all the memory, 4 bits per filesystem block, we record what > type of information is in that part of the fs - including free blocks. When it allocates more than it actually faults in then this tweak may help. -Andi |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: 1st message - xfs as a module under RH 7.3, Eric Sandeen |
|---|---|
| Next by Date: | xfs_fsr usage, Marc Kaplan |
| Previous by Thread: | Re: unable to use xfs_repair, Steve Lord |
| Next by Thread: | Re: unable to use xfs_repair, Steve Lord |
| Indexes: | [Date] [Thread] [Top] [All Lists] |