Re: blocksizes

[Michael van Elst <mlelstv%serpens.de@localhost>]

On Sun, Jan 24, 2010 at 09:08:10AM -0800, John Nemeth wrote:

>      A quote, often attributed to Einstein, is, "Everything should be
> made as simple as possible, but no simpler."  I can't help but feel
> that this is making things simpler then they should be.

John, you misunderstand this.

NetBSD already uses DEV_BSIZE units to address disks. This is no
change at all. We just need to use this in all places consistently
which requires a few fixes.

Not using DEV_BSIZE requires to change how things work now.


> } No, the driver will not support writes of single 512byte sectors
> } if the underlying hardware does not provide 512byte sectors.
> 
>      How do you communicate the real blocksize up the stack?

Currently disk drivers have two means:

- the basic driver uses the disklabel to communicate the information

- the dk driver provides a wedge info which does not include
  the real blocksize, but it references the 'parent driver'
  and the related information stored in the 'struct disk'
  data structure which includes things like the block shift.


> If you're
> doing writes from userland through the raw device, how do you find out
> the real blocksize?

- the basic driver uses the disklabel to communicate the information

- the dk driver provides a wedge info which does not include the
  real blocksize. However, you can use the drvctl driver to query
  the related information stored in the 'struct disk' data
  structure which includes the sector size. This is how the
  gpt tool does it now.

Neither is really nice to use. _is_ as in _now_ and for quite some
years now. However, this has little to do with the problem at hand.


> } We are only talking about the API and what units are used to
> } specify disk addresses and block counts. So on a disk with
> } 1K sectors you will address blocks 0,2,4,6,... and you can
> } only transfer an even number of blocks.
> 
>      Other then simplifying things possibly beyond the point they
> should be, what is the point of keeping DEV_BSIZE when you are going to
> force everything to use the real blocksize?


I am not forcing anything. I am not changing anything except for a
few fixes that currently prevent the use of large sectors.

Since I am not changing anything this is the basic reason to keep
DEV_BSIZE as is. The reason is: to avoid lots of changes.


> } N.B. So far I have MSDOSFS and FFS running on a disk with 1K sectors
> } and I learned that the block size translation is already done
> } in our block drivers, so there is no need to funnel I/O through dk.
> 
>      It is certainly good to have a proof of concept.

I think the best is to just ignore your chatter.


-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."