[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fwd: ext2fs patch for large stores, RC1+20040304]

From: Ognyan Kulev
Subject: Re: [Fwd: ext2fs patch for large stores, RC1+20040304]
Date: Sun, 18 Apr 2004 12:56:34 +0300
User-agent: Mozilla Thunderbird 0.5 (X11/20040306)

Michael Banck wrote:
I tested this a bit by compiling glibc on  2.4GB partition. It seems to
work quite well at first, but after a while, I got a couple of errors.
Most of them were plain freezes or Resource lost. I also had quite some
filesystem corruption when (forcibly) checking the file system. After
reverting the patch and to a smaller partition, I was able to build
glibc without problems :-/

Thank you for testing the patch :-)

ext2fs.static: ../../ext2fs/pager.c:1045: disk_cache_block_ref:
        Assertion '0 <= block && block <= store->size >>
        log2_block_size' failed.

It seems that somewhere in code invalid block number (e.g., with highest bit set) is used. Backtrace is very valuable for finding where is the problem. I'll try to reproduce this bug.

Also, I noticed that I am no longer able to mount my (rather small) root
GNU/Linux partition, as it has less than 4kb blocks. I don't remember
specifying anything special when I install GNU/Linux, so I wonder
whether this is expected to be fixed/resolved?

The patched ext2fs doesn't work with block sizes != 4K. If this is requirement for committing the patch, I'll fix it, if it's not, I prefer to address it later. It's known fact that current ext2fs has problems with block sizes != 4K, but I don't know what are they.

And don't forget that if you test the patch, you'll probably want
patched e2fsprogs too.  You can get the patch from
http://debian.fmi.uni-sofia.bg/~ogi/hurd/ext3fs/ .  It applies cleanly
to e2fsprogs_1.35-2 (with some offsets, but without *.rej files).

Did you try to get it applied upstream?

No, Marcus Brinkmann says we have to fix the 2G limit for files ourselves. Original e2fsprogs uses Unix API (read/write syscalls on files) for working on file systems. The Hurd API is 64-bit, but implementations (e.g. ext2fs and storeio) use libpager for all read and write operations, and libpager can't handle mappings (e.g. of files and devices) larger than 2G. So either libpager's usage must be replaced with something else, or libpager should become 64-bit. I have thought only about the latter, and it's not easy at all. IMHO We should think again about applying the e2fsprogs patch.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]