2GB memory limit running fsck on a +6TB device

Bryan Kadzban bryan at kadzban.is-a-geek.net
Wed Jun 11 16:49:04 UTC 2008


On Wed, Jun 11, 2008 at 08:59:08AM -0600, Andreas Dilger wrote:
> On Jun 11, 2008  13:51 +0200, santi at usansolo.net wrote:
> > On Wed, 11 Jun 2008 10:14:45 +0200, <santi at usansolo.net> wrote:
> > 
> > >> Moving /var/cache/e2fsck to another disk partition will help (or
> > >> better yet, battery backed memory device), but the best thing you
> > >> can do is get a 64-bit kernel and not need to use the auxiliary
> > >> storage in the first place.
> > > 
> > > I'm trying a fast test with "mount tmpfs /var/cache/e2fsck -t tmpfs
> > > -o size=2048M", but appears that will take a long time to complete
> > > too.. so the next test will be with a 64-bit LiveCD :)
> > 
> > Note that putting '/var/cache/e2fsck' in a memory filesystem is aprox.
> > 3 times faster ;-)
> 
> ...but, isn't the problem that you don't have enough RAM?  Using
> tdb+ramfs isn't going to be faster than using the RAM directly.

It won't be faster, no, but it will be faster than tdb-on-disk, and much
faster than tdb on the same disk as the one that's being checked.

And it *might* allow e2fsck to allocate all the virtual memory that it
needs, depending on how the tmpfs driver works.  If tmpfs uses the same
VA space as e2fsck and the rest of the kernel, then it probably won't
help.  But if tmpfs can use a different pool somehow (whether that's
because the kernel uses a different set of pagetables, or whatever),
then it might.

> I suspect that the only way you are going to check this filesystem
> efficiently is to boot a 64-bit kernel (even just from a rescue disk),
> set up some swap just in case, and run e2fsck from there.

And try to run a 64-bit e2fsck binary, too.  The virtual address space
usage estimate that someone (Ted?) came up with earlier in this thread
was close to 4G, which means that even with a 64-bit kernel, a 32-bit
e2fsck binary might still run out of virtual address space.  (It will
need to map lots of disk, plus any real RAM usage, plus itself and any
libraries.  That last bit *might* push it over 4G, depending on how
accurate the estimate of 4G turns out to be.)

The easiest way to do this is probably run the e2fsck from the LiveCD
itself; don't try to run the 32-bit version that the system has
installed.  That version *might* work, but it'll be tight; a 64-bit
version that can use 40-odd bits in its virtual addresses (44?  48?  I
think it depends on the exact CPU model -- and the kernel, of course)
will have a *lot* more headroom.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/ext3-users/attachments/20080611/ce465b98/attachment.sig>


More information about the Ext3-users mailing list