On Thu, Jan 20, 2011 at 02:37:37PM +0800, Li, Shaohua wrote: > On Thu, 2011-01-20 at 14:19 +0800, Wu, Fengguang wrote: > > On Thu, Jan 20, 2011 at 02:12:33PM +0800, Li, Shaohua wrote: > > > On Thu, 2011-01-20 at 13:55 +0800, Andrew Morton wrote: > > > > On Thu, 20 Jan 2011 13:38:18 +0800 Shaohua Li <shaohua...@intel.com> > > > > wrote: > > > > > > > > > > ext2, minix and probably others create an address_space for each > > > > > > directory. Heaven knows what xfs does (for example). > > > > > yes, this is for one directiory, but the all files's metadata are in > > > > > block_dev address_space. > > > > > I thought you mean there are several block_dev address_space like > > > > > address_space in some filesystems, which doesn't fit well in my > > > > > implementation. for ext like filesystem, there is only one > > > > > address_space. for filesystems with several address_space, my proposal > > > > > is map them to a virtual big address_space in the new ioctls. > > > > > > > > ext2 and minixfs (and I think sysv and ufs) have a separate > > > > address_space for each directory. I don't see how those can be > > > > represented with a single "virtual big address_space" - we also need > > > > identifiers in there so each directory's address_space can be created > > > > and appropriately populated. > > > Oh, I misunderstand your comments. you are right, the ioctl methods > > > don't work for ext2. the dir's address_space can't be readahead either. > > > Looks we could only do the metadata readahead in filesystem specific > > > way. > > > > There should be little interest on ext2 boot time optimization. > > > > However if necessary, we might somehow treat ext2 dirs as files and > > do normal fadvise on them? The other ext2 metadata may still be > > accessible via the block_dev interface. > current readahead syscall might already work here. however, I would > expect there is stall easily when reading dirs. > thinking 3 dirs: > / > /aa > /aa/bb > before / is in memory, reading aa will have stall. And we can't reduce > disk seeks here. metadata readahead will still have some benefits but > might not be much in such filesystem.
Yeah, good point. Thanks, Fengguang -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
