Hi Jörn, On Thu, 18 Sep 2008 00:49:53 +0200, Jörn Engel wrote: > On Thu, 18 September 2008 04:09:45 +0900, Ryusuke Konishi wrote: > > If so, the remaining problem would be the lock dependencies as you > > mentioned before. > > You should have the same problem already - in some shape or another. If > you can have two data structures for the same content, a real inode and > a dummy inode, you have a race condition. Quite possibly one involving > data corruption. > > Well, one way to avoid both the race and the locking complexity is by > stopping all writes during GC and destroying all dummy inodes before > writes resume. The current version of NILFS2 really takes this approach. Pages held by the dummy inodes will be released after they are copied to a new log. > 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. Hmm, we would be better off counting frequency of true overlap if getting to that. > BTW: Some of the explanation you just gave me would do well as > documentation in the source file as well. That's the sort of background > information new developers can spend month of mistakes and reverse > engineering on. :) > > Jörn Well, thanks. I'll do that. NILFS2 needs explication than usual file systems; it needs time perspective as well as it is an LFS. :) Regards, Ryusuke -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
