On February 25, rudsve@drewag.de wrote: > "Stephen C. Tweedie" <sct@redhat.com> writes: > > > > A fair bunch of people did a fair bunch of testing of this last year. > > > Bottom line: RAM-based journals don't speed ext3 up. > > > > Well, they did, but in general it was no better than adding an > > external disk-based journal. > > So I want to use a small RAID-1 to hold the journal for the 600GB > RAID-5-based FS. Should be OK? Yep, I do this. Seems to work OK. You need the very latest e2fs-utils. (or disable fsck for that partition and let the kernel replay the journal on a crash). > > I haven't found hints on sizing the external journal. How big should > it be, and how do configuration factors (journalling mode e.g.) > influence this? As has been mentioned, it depends. I use my bigish RAID5 array as an NFS server. This means lots of synchronous writes. So I use data=journal. I have noticed that if the journal ever gets full, the throughput pauses for a while until every transaction in the journal has been checkpointed onto the main device. One way to avoid this is to reduce the flush time by altering /proc/sys/vm/bdflush. This way transactions get flushed to disc before the journal fills. Another is to make the journal sufficiently big that it will never fill (i.e. the default flush time will flush out transactioned before ext3 tries to checkpoint them). I took the second approach and made the journals rediculously large (3Gb!). This seems to work ok, but makes replay time fairly slow after a crash. This seems to be due to the journal replay making 3 passes through the journal (I think). I have had a 15minute pause to replay the journal. This is much better than 90 minutes to fsck, but isn't ideal. Next time, I will probably make the journal a bit smaller. Actually, next time I hope to have the journal on an NVRAM, which will be 1GB. I don't know if I'll need to tune bdflush with a 1Gb journal. NeilBrown
