This is all very thoroughly thought out, but I guess I don't see why such
a massive set of changes need to be made. As long as device drivers
remember that every in the system that refers to 'blocks' is in DEV_BSIZE
units, the device driver can adjust transfers accordingly. The difficult
case is in doing the partial device sector transfer in the case that
the device sector size is larger than DEV_BSIZE- but this can be handled
with a private slop sector allocation and judicious uses of copy functions.
Gross, but not unreasonably so, as the typical access size is likely
going to be the device sector size anyway.

If the population of devices with different sector sizes were more evenly
distributed there might be more of a justification for re-engineering
the way Unix systems handle common block siszes. However, there are
relatively few disklike devices which can't have sector sizes changed
to the more or less common 512 byte 'sector' size. The MO you talk
about is certainly one. A few CDROM devices refuse to allow logical
block size to be changed from 2048 (Nakamichi makes one). There may in
fact be edge case performance considerations for making actual larger
physical sector sizes on disks. It was certainly true for older SMD
drives that picking a 1K or 2K sector size gave you a bit more actual
storage and faster access to it (less sector overhead per track for
the h/w to skip over)), but, as I said, this is an edge case with
possibly marginal worth.

Tape devices are a different story- but they are handled differently
anyhow. I can't think of a set of commonly available devices that
would make or break the notion of having systemwide variable sector
size support. From a formal point of view, this does have appeal,
but from a practical engineering point of view I'm not sure that the
amount of breakage and turmoil is worth it.

Thoughts?

-matt