-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-Type: text/plain; charset=us-ascii
Howdy - we have a bunch of dual processor Compaqs with 180GB RAID
partitions for email, running with ext2 for the last year or so. I
thought I'd try out ext3 (on our development machine :-) to see
whether it was a practical proposition for this kind of thing yet.
Appears to be working so far, with a 300MB journal (based on the rule
of thumb in the ext3 README), but we did notice that whereas our
(RedHat) /etc/rc.d/rc.sysinit said to do a...
initlog -c "fsck -C -T -R -A -a $fsckoptions"
to check the non-root filesystems, we actually got a crash from the
fsck parent process until we changed to serialized fscking, viz.
initlog -c "fsck -s -C -T -R -A -a $fsckoptions"
If this isn't a known problem (I've only been skimmed the list
postings, so apologies if I'm rehashing old stuff here), I can attempt
to ferret out the cause...
Cheers,
Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Exmh version 2.1.1 10/15/1999 + martin
iD8DBQE6bAHHVw+hz3xBJfQRApsWAJ9WIZw7iXYzQdUpQTporKnKf4SSOwCeLU7l
EzyulNnJjfmuUMN1dYJAAV0=44s0
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-Type: text/plain; charset=us-ascii Doh! Too early in the morning :-) I should have mentioned that these machines have 1GB RAM (so journal size oughtn't to be a problem), and that this is with 2.2.19pre7, ext3-0.0.5e and e2fsprogs-1.20.WIP.sct. They're (for a variety of reasons) currently on RedHat 6.1 + patches, for all that's worth. Cheers, Martin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Exmh version 2.1.1 10/15/1999 + martin iD8DBQE6bAeoVw+hz3xBJfQRAjXIAKCgHlIRofpizDtBiHLIsIpHN4WvAACeJ2d8 TBUkHsGhK/lVmYggAxQzCi4=5f09 -----END PGP SIGNATURE-----
Martin Hamilton writes:> Howdy - we have a bunch of dual processor Compaqs with 180GB RAID > partitions for email, running with ext2 for the last year or so. I > thought I'd try out ext3 (on our development machine :-) to see > whether it was a practical proposition for this kind of thing yet. > > Appears to be working so far, with a 300MB journal (based on the rule > of thumb in the ext3 README)This is probably too large, especially if you are using ordered data journaling mode, since only metadata will be written into the journal.> we did notice that whereas our (RedHat) /etc/rc.d/rc.sysinit said to do a... > > initlog -c "fsck -C -T -R -A -a $fsckoptions" > > to check the non-root filesystems, we actually got a crash from the > fsck parent process until we changed to serialized fscking, viz. > > initlog -c "fsck -s -C -T -R -A -a $fsckoptions"Haven't read about this before. It would be good if you could tell us your e2fsprogs version. Also, if at all possible, can you build your own version of e2fsprogs (preferrably the latest WIP version) and run the unstripped fsck under gdb to find out where the crash happens.> If this isn't a known problem (I've only been skimmed the list > postings, so apologies if I'm rehashing old stuff here), I can attempt > to ferret out the cause...This would be most helpful. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
Hi, On Mon, Jan 22, 2001 at 09:47:51AM +0000, Martin Hamilton wrote:> > Appears to be working so far, with a 300MB journal (based on the rule > of thumb in the ext3 README)Actually, the rule of thumb reads Now, create a journal file. I don't know how big it should be yet: the rules of thumb have yet to be established! However, try (say) 2MB for a small filesystem on a 486; maybe up to 30MB on a big 18G 10krpm Cheetah. Note the "up to". 30MB is meant to be an upper limit on a sane journal size. The optimal journal size depends on the filesystem's write load, NOT on the size of the disk, so a 300MB journal is way too large, and will end up pinning loads of stuff into memory!> to check the non-root filesystems, we actually got a crash from the > fsck parent process until we changed to serialized fscking, viz.What sort of "crash"? It sounds as if you ended up doing several hundred MB of simultaneous journal replay because of the huge journal sizes, and the system got bogged down into seeking all over the place. That is going to be _really_ slow, but it should eventually complete. Ted, one thing I can't recall here offhand --- will e2fsck buffer all the IO channel writes until flush, or will it write as it goes? If it's buffering things, then e2fsck journal replay could end up using a lot of swap, and that's maybe something we want to fix. Cheers, Stephen