On Thu, 2011-01-20 at 12:10 +0800, Andrew Morton wrote: > On Thu, 20 Jan 2011 11:21:49 +0800 Shaohua Li <shaohua.li@xxxxxxxxx> wrote: > > > > It seems to return a single offset/length tuple which refers to the > > > btrfs metadata "file", with the intent that this tuple later be fed > > > into a btrfs-specific readahead ioctl. > > > > > > I can see how this might be used with say fatfs or ext3 where all > > > metadata resides within the blockdev address_space. But how is a > > > filesytem which keeps its metadata in multiple address_spaces supposed > > > to use this interface? > > Oh, this looks like a big problem, thanks for letting me know such > > filesystems. is it possible specific filesystem mapping multiple > > address_space ranges to a virtual big ranges? the new ioctls handle the > > mapping. > > I'm not sure what you mean by that. > > 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. snip > I'm not sure any of that was very useful, really. A full-on coldboot > optimiser really wants visibility into every disk block which need to > be read, and then mechanisms to tell the kernel to load those blocks > into the correct address_spaces. That's hard, because file data > depends on file metadata. A vast simplification would be to do it in > two disk passes: read all the metadata on pass 1 then all the data on > pass 2. This is exactly what my patch does. We use the new ioctls to do metadata readahead in first pass, and do data readahead in the second pass. > A totally different approach is to reorder all the data and metadata > on-disk, so no special cold-boot processing is needed at all. not feasible for a product and it's very hard for some filesystmes. > And a third approach is to save all the cache into a special > file/partition/etc and to preload all that into kernel data structures > at boot. Obviously this one is ricky/tricky because the on-disk > replica of the real data can get out of sync with the real data. Tricky staff. -- 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
