Re: [PATCH v3 1/5] add metadata_incore ioctl in vfs

[Wu Fengguang <fengguang.wu@xxxxxxxxx>]

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.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.

Yeah, good point.

Thanks,
Fengguang

--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html