Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU |
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.
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |