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.li@xxxxxxxxx> 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. Thanks, Shaohua -- 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
