Documentation on ext3?

[jc at trillian.mit.edu (John Chambers)]

dsr wrote:
| You convert an ext2 to an ext3 by using the tune2fs command to add a
| journalling option, then remounting the filesystem.
|
| You convert an ext3 back to an ext2 by mounting it explicitly as an
| ext2, which will invalidate the journal.

Ah, so I did it right by accident. ;-)

| the k*d processes are kernel processes which are accounted for
| separately from the kernel proper. However, the code for them is
| entirely within the kernel itself.

I'd wondered about that. I've heard of "kernel processes", but so far
everything  I've read about them is mystical poetry.  They apparently
don't work through the usual process hooks.

| kupdated flushes dirty blocks from the caches. Tune it in
| /proc/sys/vm/bdflush.
|
| http://batleth.sapienti-sat.org/projects/FAQs/ext3-faq.html

Thanks.  I didn't find that one through google, and it looks like  it
might  have  some  useful  info.   Maybe it's off in the 17th page of
google matches ...

It's entirely possible that the problem has to do with  tuning.   The
things  I'm working on are attempting to create and/or destroy flocks
of small files.  When running, they seem to  be  able  to  create  or
unlink several hundred files per second on the hardware at hand.  But
when kjournald wakes up, the file creation/deletion  speed  drops  to
under 10 per second.

In a situation where files are being created and  destroyed  rapidly,
I'd  think  that  a  journaling  file system might not be a very good
idea.  It's sorta based on the idea that if something  is  lost,  you
want  to be able to recover it.  But in this case, we want to get rid
of files and reuse the space.

One problem is that the machine is somewhat distant, across the  net.
I could travel to it, but it would be a real hassle and loss of time.
I'm trying to do it all across the net.  I suppose this is a  growing
fact of life for a lot of us.  So you can't look at the blinkenlights
to quickly spot either activity or hardware problems.