Messages in this thread | | | Date | Sat, 19 Jun 1999 13:11:51 +0200 | From | Pavel Machek <> | Subject | Re: Speeding up fsck 2 times |
| |
Hi!
> > 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/
| |