Nathan Roberts wrote: > Has a feature ever been considered (or already exist) for storing inodes > in a block device separate from the data? Is it even a "reasonable" > thing to do or are there major pitfalls that one would run into? XFS has such a thing, although it evolved for slightly different reasons. The "realtime subvolume" is a data-only volume, with all metadata on the main block device. It also has some different allocator characteristics. In practice I don't think it's been used much in the field on Linux, but ISTR some people have had good luck for some workloads. > The rationale behind this question comes from use cases where a file > system is storing very large numbers of files. Reading files in these > file systems will essentially incur at least two seeks: one for the > inode, one for the data blocks. If the seek to the inode were more > efficient, dramatic performance gains could be achieved for such use cases. > > Fast seeking devices (such as flash based devices) are becoming much > more mainstream these days and would seem like a reasonable device for > the inodes. The $/GB is not as good as disks but it's much better than > DRAM. For many use cases, the number of these "fast access" inodes that > would need to be cached in RAM is near 0. So, RAM savings are also a > potential benefit. One downside may be flash wear; in a hand-wavy way I could imagine that data blocks may change less often than metadata in many use casees (think atimes, directory updates and whatnot). Just a thought. > I've ran some basic tests using ext4 on a SATA array plus a USB thumb > drive for the inodes. Even with the slowness of a thumb drive, I was > able to see encouraging results ( >50% read throughput improvement for a > mixture of 4K-8K files). How'd you test this, do you have a patch? Sounds interesting. Thanks, -Eric > I'm interested in hearing thoughts/potential pitfalls/etc. > > Nathan > > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" 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-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
