On Thu, 18 September 2008 04:09:45 +0900, Ryusuke Konishi wrote: > > > Using dummy inodes is... unusual. Why can you not use the actual inodes > > those blocks belong to? > > Because we have to treat blocks that belong to a same file but have > different checkpoint numbers. (NILFS2 keeps up multiple > checkpoints/snapshots across GC) > > Of course, if the standard inode hash is applicable, I prefer it. > ilookup5 or its variant may be applicable for this. If that is possible I would definitely prefer it. > 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. 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. So unless I missed something important, I believe the locking is well worth the effort. 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 -- Those who come seeking peace without a treaty are plotting. -- Sun Tzu -- 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
