On Wed, 27 August 2008 01:54:30 +0900, Ryusuke Konishi wrote: > On Tue, 26 Aug 2008 12:16:19 +0200, Jorn Engel wrote: > > > >Interesting approach. Does that mean that every block lookup involves > >two disk accesses, one for the DAT and one for the actual block? > > Simply stated, it's Yes. > > But the actual number of disk accesses will become fewer because the DAT is > cached like regular files and read-ahead is also applied. > The cache for the DAT works well enough. Yep. It is not a bad tradeoff. You pay with some extra seeks when the filesystem is freshly mounted but gain a lot of simplicity in garbage collection. More questions. I believe the first two answer are no, but would like to be sure. Do you support compression? Do you do wear leveling or scrubbing? How does garbage collection work? In particular, when the filesystem runs out of free space, do you depend on the userspace daemon to make some policy decisions or can the kernel make progress on its own? Jörn -- There are two ways of constructing a software design: one way is to make it so simple that there are obviously no deficiencies, and the other is to make it so complicated that there are no obvious deficiencies. -- C. A. R. Hoare -- 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
