I noticed this activity as well quite a while back. It's not limited to 'rm'. I also wrote a similar test script with 'mv' and even a 'hello-world' with 'rename' to continuously rename a file from 'foo.0' to foo.fffffff and the drive light just went _crazy_. As you observed, the same sort of thing under Linux operates almost entirely in disk and fileystem cache.
I understand the goals of having disk syncrhonization performed in the proper order to avoid disk inconsistencies. I also, however, agree with Adam that something less than "optimal" might be better than nothing at all. > Linux, IIRC, simply ignores the issue entirely, and hopes you don't > get screwed. And when I get screwed, e2fsck fixes it for me most of the time. For instance, a simple LRU cache algorithm implemented in 'libstore' might provide a large performance advantage with the caveat that it might occasionally lead to disk inconsistencies. This is a performance trade-off I'm willing to make. i.e. I'm willing to gamble the risk of data loss on some filesystems in exchange for, say, building 'glibc' more than once in 24 hours (slight exageration). Perhaps I'll pull out 'bonnie' and some other test programs to provide some relative performance numbers under the Hurd v.s. Linux just to quantify the trade-off being made. -- Jonathan S. Arney Software Engineer [EMAIL PROTECTED] ------------------------------------------------------------------------ Some people call me a nihilist. That would be true except I don't believe in nihilism. ------------------------------------------------------------------------ _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
