On Sat, Oct 08, 2005 at 02:37:21PM +0200, Reinoud Zandijk wrote:
> Wouldn't it then be the time to also scrap the fixed DEV_BSIZE blocksize 
> interface to discs to replace it with a *sector-size* oriented interface so 
> various filingsystems like msdosfs and udf eventually can support non 512 
> bytes/sector filingsystems?

if we were to change the units of all the interfaces that currently
use DEV_BSIZE implicitly, I'd much rather see us move to bytes than to
a variable unit like the device sector size.  say you have a virtual device
that is backed by two physical devices with different sector sizes,
what would you use for the virtual device's sector size?  (well, here
you could always use the largest sector size of the physical devices.)
but what if a virtual device is changed to be backed by a different
physical device of a larger sector size?  how can anything that caches
the sector size know that it has changed?  even if ever caller re-fetches
the sector size every time, there's still a race unless there were some
sector-size-lock.  let's not even go there.

using bytes as the unit for the interface would avoid all such issues.

but I don't think that we really need to change the units in the first place,
the existing patches to support non-512-byte sector sizes would be sufficient.


> There has been several patches around for yonks that fixes these issues but 
> they were never integrated. Our msdosfs f.e. doesn't support non 512 
> bytes/sector devices. Filingsystems DO change on sectorsize and devices 
> like DVD/CD+-(M)R(W) can't just do read-modify-write cycle to cope with 
> blocksizes smaller than the sector size.

all of the devices that I know of with such restrictions on writing have
a sector size of 512 bytes or larger, so this isn't an issue in practice.

-Chuck