On Wed, Jun 11, 2008 at 08:59:08AM -0600, Andreas Dilger wrote: > On Jun 11, 2008 13:51 +0200, santi@xxxxxxxxxxxx wrote: > > On Wed, 11 Jun 2008 10:14:45 +0200, <santi@xxxxxxxxxxxx> 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.
Attachment:
pgpvlB6VBxUid.pgp
Description: PGP signature
_______________________________________________ Ext3-users mailing list Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users
