Re: blocksizes

[Matt Thomas <matt%3am-software.com@localhost>]

On Jan 22, 2010, at 4:09 AM, Michael van Elst wrote:

> On Fri, Jan 22, 2010 at 07:36:15PM +0900, Izumi Tsutsui wrote:
>>> disk devices are accessed in units of 'blocks', a block can be
>>> any size, however NetBSD makes assumptions in many places that
>>> a block is 512 bytes or DEV_BSIZE bytes which makes it impossible
>>> to use devices with different block sizes.
>>> 
>>> IMHO there need to be three different ways to specify block
>>> offsets and block counts:
>>> 
>>> 1. in units of blocks of the physical device
>>> 2. in units of blocks of DEV_BSIZE bytes
>>> 3. in bytes
>>> 
>>> and we need to establish what units are used where.
>>> 
>>> 
>>> One possible path to support devices where physical blocks are
>>> not of size DEV_BSIZE would be
>>> 
>>> - device drivers use 1.
>>> - wedges use 1.
>>> - the dk driver translates between 1. and 2.
>>> - the buffer system uses 2. and 3.
>>> 
>>> Filesystems can be pretty agnostic to this as any multiple of DEV_BSIZE
>>> will work (but slower if not properly aligned to the physical block size).
>>> 
>>> The necessary changes are rather small. In particular, dkwedge_info needs
>>> to be extended to keep track of the physical sector size so that the dk
>>> driver can do the transformations.
>> 
>>> 
>>> Comments?
>> 
>> - What's the reason to keep DEV_BSIZE constant? Less necessary changes?
> 
> Keeping DEV_SIZE at 512 bytes avoids lots of changes.

So?

> I think about doing block size translations only in the dk driver.
> Changing DEV_BSIZE would break lots of things if you use the
> parent device (like wd) directly and I am sure that we will have
> users of dk and users of the parent devices at the same time.

My feelings are this: when accessing the device through a bdevsw (d_psize or 
d_strategy), will refer to daddr_t and will be units of the blocksize of the 
device.  For block access (aka filesystem) only blocksize that are powers of 2 
will supported.

For raw device access, any native blocksize can be used (like 2352 for CD 
audio).

The btodb/dbtob macros will need another argument to indicate where the block 
size is obtained.