Martin K. Petersen wrote: > The phys_off value I export for the MD device is the offset for the > first device. But that does not imply that the other devices in the > stripe have the same alignment. There are setups where the offsets of subdevices are modulo-aligned well for performance, and when they aren't. When they conflict for poor performance, it's useful to be informed. > I considered taking an approach similar to blk_queue_stack_limits() > where you clamp using the existing values as you add more devices. Makes some sense. > The downside to that is that you really want to let the user know that > there's a potential problem. As long as the measurement presented is one which looks worse and worse when you combine subdevices, they will see from the bad-looking value. A flag is a nice bonus, but the main thing is, e.g. "the largest combined stripe size for the device is 8 sectors" due to poor offset skew, instead of 1024 sectors, say. > And requiring the user to scrounge > through syslog to look for complaints isn't so happening. I'd much > rather do that in libdisk where it's easy to print a message about > "Suboptimal layout, proceed with caution". I agree, that is good. Where it is due to specific values being not exactly right - like the subdevice offset (or modulo-offset) in MD because it doesn't represent all subdevices - it would be good for the info to have flags saying which _specific_ values are not exactly right. So that programs can choose their heuristics appropriately. After all, users will use suboptimal layouts, and still want the best performance it can do. -- Jamie -- 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
