> > I'm slowing down data operation by 5% or so. (Don't know how to
> > benchmark this).
>
> This 5% is worthless: it could be 0.1% as it could be 50%. Without a
> fair benchmark, you don't know.
I unfortunately can not do the test. For fair benchmark, I need
partition which is _much bigger_ than my ammount of RAM. I have one
such partition, but it is my / partition and I'm not willing to
scratch it. (And loop test would be worthless because it depends on
layout of loop file.)
Also, it is not clear what "fair benchmark" is. Linear file creation?
Random access?
> But people who scream for journalling don't just want a faster fsck, they want
> an "instantaneous" fsck (at least: mostly independent from the size of the
> disk). I'm not willing to lose 5% performance in order to win just
I think that I can strip fsck down much more than 2 times, but it
starts to be evil. Basically putting all indirect blocks into group 0
and then lineary-reading group 0 just before fsck so that metadata sit
firmly in the cache.
This could speed up fsck from 6 minutes to 20 seconds or so.
Pavel
PS: For journalling: are you sure it will speed up your boot?
When machine is booting up, it does not know if reboot is due to power
failure or due to sw crash. [Actually, big machines tend to have UPSs
so power failures are not too common.] In case of sw crash you have to
do fsck. But machine can not know if it crashed due to sw crash or due
to power fail -- so I expect it to do full fsck anyway.
I'm told that when you force-fsck NT they find some FS corruption over
extended periods of time, so that "fsck-after-crash" might give sense
after all.
-- I'm really pavel@ucw.cz. Look at http://195.113.31.123/~pavel. Pavel Hi! I'm a .signature virus! Copy me into your ~/.signature, please!- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/