Posted Apr 27, 2007 5:31 UTC (Fri) by pimlott
In reply to: chunkfs
Parent article: Filesystems: chunkfs and reiser4
I'm not sure if I followed exactly what you meant in some places, so let me try and ask you to correct me.
it's not that you avoid dong the fsck on some chunks, it's that you don't have to try and track the state of the entire filesystem at once so the check is faster.
Are you saying here that the total fsck time of all N chunks is less than the fsck time of a normal filesystem? That's probably true, but it doesn't solve the fundamental scaling problem of full partition fsck (does it?).
if some chunks haven't been modified since they were last chaned (and can therefor be clean) that just speeds up the searh
Is "chaned" meant to be "changed"? "haven't been modified since they were last changed" doesn't make sense, however. Do you mean that if a chunk has not even been touched since the last fsck, it doesn't need to be fscked again? Well ok, but I doubt that's going to be a common case. If you mean that chunks that are not dirty after a crash don't need to be fscked, that only applies to a non-journaling filesystem (does anyone still use those?).
The premise, I thought, was that the whole filesystem needs to be fscked from time to time, because stuff happens. No matter how clever you are, stopping stopping the world to check the whole partition will not scale. So on-line fsck of chunks looks like the real win to me.
to post comments)