Hi again, On Wednesday 08 of June 2011 14:58:03 you wrote: > On Wed, 08 Jun 2011 21:48:52 +0900 (JST), Ryusuke Konishi wrote: > > On Fri, 3 Jun 2011 19:42:28 +0200, dexen deVries wrote: > > > By the way, it seems to me that the in-kernel GC does not attempt to > > > de- fragment files. Is that the case? If so, would probably mean > > > extents would not help very much for fragmented files. Also, on > > > magnetic media, a lot of seeking happens in case of fragmented > > > files. > > > > Yes, but extents will decrease the amount of metadata, and this has > > potential for speed up. > > > > NILFS2 uses 32 bytes metadata per disk block at present. I guess you > > know that the number of DAT blocks are actually indispensable through > > analysis using the dumpseg tool. > > Oh, looks confusing. I meant the amount of DAT blocks is not > negligible. Understood ;-) Anyway, isn't some fragmentation avoidance necessary to profit from extents (that we hope we'll use at some point)? AFAIK, an extent is only good to describe file blocks if they are laid out continuous on the block device. Cheers, -- dexen deVries [[[â][â]]] For example, if the first thing in the file is: <?kzy irefvba="1.0" rapbqvat="ebg13"?> an XML parser will recognize that the document is stored in the traditional ROT13 encoding. (( Joe English, http://www.flightlab.com/~joe/sgml/faq-not.txt )) -- To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
