On Thu, Jan 21, 2010 at 10:30:20PM +0000, Michael van Elst wrote: > Hello, > > > 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). As noted in another EMail, when we last dived into everything, the decision was to do everyhing in "2". i/o however had to be in full blocks. So on a 2k disk, you can do 4-DEV_BSIZE transfers, 8-DEV_BSIZE, and so on. The driver can and should spit at you if you try to do sub-block i/o. > 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. Having gotten NetBSD running on 1k disk drives in Feb 2000, I disagree that the changes are small. I actually went down the path of your "1" and changed everything to fit. I changed jobs, and by the time I was back at NetBSD, we had gone with "2". Take care, Bill
Attachment:
pgpOvHz10qctf.pgp
Description: PGP signature