Re: blocksizes

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

> 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?
- Do you mean wedge and dk(4) are mandatory to use !512bytes/sec disks?
- Can we use filesystems on raw devices without label on !512bytes/sec disks?
- What about pseudo disk devices like vnd(4), cgd(4), and raid(4)?
- What value should be used for d_secsize in struct disklabel?
- UFS file systems have "disk block size" parameters in their superblocks
  as fs_fsbtodb etc. Which should it be, 1. or 2.?
  Current newfs(8) uses sectorsize (physical block size) to set it, but
  fs code passes block numbers calculated by fsbtodb to buffercache(9).

IMO, such "less necessary changes" will include much more logical hacks
which will confuse future developers, as current inconsistent implementation.

I wonder if 512bytes/sector will become legacy or not in future..
---
Izumi Tsutsui