On Sat, 20 September 2008 19:43:58 +0900, Ryusuke Konishi wrote:
quoted text
> 
> > But that would be inefficient in several cases.  When
> > GC'ing data that is dirty in the caches, you move the old stale data
> > during GC and write the new data soon after.  And you always flush the
> > caches after GC, even if your machine has no better use for the memory.
> 
> As for as NILFS2, the dirty blocks and the blocks to be moved by GC
> never overlap because the dirty blocks make a new generation.
> So, they rather must be written individually.
> 
> Though we can reuse pages in the GC cache, the effect of this
> optimization may be much lower than usual LFSes because most of
> blocks in the pages may not belong to the latest generation.

Yet again I've tried to apply techniques that simply don't work with
checkpoints in the equation.

quoted text
> NILFS2 needs explication than usual file systems; it needs time
> perspective as well as it is an LFS. :)

At least if you take me as a standard, I think you have proven that
point rather well. :)

Jörn

-- 
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it.
-- Brian W. Kernighan
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/