Shaohua, On Tue, Jan 04, 2011 at 01:40:30PM +0800, Li, Shaohua wrote: > Hi, > We have file readahead to do asyn file read, but has no metadata > readahead. For a list of files, their metadata is stored in fragmented > disk space and metadata read is a sync operation, which impacts the > efficiency of readahead much. The patches try to add meatadata readahead > for btrfs. > In btrfs, metadata is stored in btree_inode. Ideally, if we could hook > the inode to a fd so we could use existing syscalls (readahead, mincore > or upcoming fincore) to do readahead, but the inode is hidden, there is > no easy way for this from my understanding. So we add two ioctls for If that is the main obstacle, why not do straightforward fincore()/ fadvise(), and add ioctls to btrfs to export/grab the hidden btree_inode in any form? This will address btrfs' specific issue, and have the benefit of making the VFS part general enough. You know ext2/3/4 already have block_dev ready for metadata readahead. Thanks, Fengguang > this. One is like readahead syscall, the other is like micore/fincore > syscall. > Under a harddisk based netbook with Meego, the metadata readahead > reduced about 3.5s boot time in average from total 16s. > Last time I posted similar patches to btrfs maillist, which adds the > new ioctls in btrfs specific ioctl code. But Christoph Hellwig asks we > have a generic interface to do this so other filesystem can share some > code, so I came up with the new one. Comments and suggestions are > welcome! > > v1->v2: > 1. Added more comments and fix return values suggested by Andrew Morton > 2. fix a race condition pointed out by Yan Zheng > > initial post: > http://marc.info/?l=linux-fsdevel&m=129222493406353&w=2 > > 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 -- 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
