>The new file >system puts data and meta-data on different devices (usually, two >partitions on the same disk or different disks), [...] I can intuitively see the benefits in terms of disk arm motion. For example, mkfs, fsck, and chmod -R would involve seeks entirely within the metadata partition, which might be 5% the size of the data partition. If the disk arm spends half its time accelerating and half decelerating, then seeking a certain distance D, should take roughly sqrt(D) time, so reducing this average seek distance when metadata operations follow each other would reduce average disk arm motion time by a factor of almost 4.5, although rotational delays would be unaffected. It is also possible that your log structured metadata file system might be improving locality further by separating unused blocks from used blocks on the scale of disk tracks. When disk reads a sector in a segment of a log structured file system, the disk drive will bascially cache the whole track, and the other sectors on that track will be more likely to have valid data, thanks to the cleaner. Of course, this has to be compared to similar benefits from the layout policies other file systems. On another subject, it would reduce system administration overhead down to the level of other file systems if your file system could could run on a single logical device and just have a policy of having the metadata area concenrtated in a particular place on the logical device (probably the middle), so that the file system would automatically accomodate changing ratios of data to metadata. This would also make it easier to run the whole thing on an interleaved RAID. Retaining the ability to put metadata on a separate device would still be useful for putting metadata in a different type of device (such as a faster spinning disk or flash). Adam Richter - 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
