>>>>> "Neil" == Neil Brown <neilb@xxxxxxx> writes: Neil> Here you're thinking seems be very specific. This value comes Neil> from that spec. That value is used for this particular Neil> application. Yet.... [...] Neil> ...here you are being deliberately vague. But with the exact same Neil> values. I find this confusing. That's because I distinguish between hardware-imposed limits and software-imposed ditto. You don't think there's a difference. I do. We don't have any control whatsoever over the hardware limits. We do have full control over the software ones. hw_sector_size is dead and has been replaced with logical_block_size and physical_block_size to accommodate new hardware devices. That's all there is to that. Full stop. The presence of lbs and pbs is completely orthogonal to I/O hints provided by hardware as well as software RAID devices. The only thing the two concepts have in common is that we need to make sure that any hints applied by stacking drivers are compatible with the underlying storage limitations. You could argue that an MD device shouldn't have logical and physical block size exposed at all. To some extent I agree. However, some applications actually *do* require intimate knowledge about the hardware. Consequently I am in favor of having the knobs exposed. Besides, the values are also being used extensively by the stacking logic. The desire to have knowledge about the hardware is not exclusively a storage thing. Page size, for instance. Most applications don't care about the page size. That doesn't mean we remove getpagesize() or pack it into something that applies equally well to all applications (memory_allocation_granularity() !?). It is a knob that available for the few applications that need it. The same goes for physical_block_size. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
