On Wed, Jul 25, 2007 at 10:46:25PM -0700, Bill Stouder-Studenmund wrote:
> On Wed, Jul 25, 2007 at 10:41:06AM -0400, Stephen M. Rumble wrote:
> > Quoting Bill Stouder-Studenmund <wrstuden@netbsd.org>:
> > 
> > >So I doubt that the EFS file system on that CD Rom is not going to use any
> > >block sizes smaller than 2K. So you don't need to read 2K sectors then
> > >split them up.
> > 
> > Is the 'not' above unintended? EFS definitely does not have variable  
> > block sizes. It's absolutely fixed at 512 bytes. Further, SGI always  
> > shipped 512b addressable drives, so far as I'm aware.
> 
> The 'not' was unintended.
> 
> If EFS really really needs files smaller than device blocks, you need to 
> use something like vnd. I don't envision us ever hacking the buffer cache 
> to handle sub-device-block entities.

Could the driver (cd) be taught to support 512b requests from upper layers
by splitting sectors itself? That is, effectively pretend that the device
block is 512b?

Actually this is apparently already implemented. cd.c contains:
-----
	/*
	 * If the disklabel sector size does not match the device
	 * sector size we may need to do some extra work.
	 */
	if (lp->d_secsize != cd->params.blksize) {

		/*
		 * If the xfer is not a multiple of the device block size
		 * or it is not block aligned, we need to bounce it.
-----

But apparently you need to set sector size in the disklabel to 512b
otherwise cdstrategy will reject such requests.

Maybe it is easier than teaching other parts of the kernel that
DEV_BSIZE is not a constant.

What is the "device block" for devices that can perform reads in smaller
chunks than writes, anyway? The write unit size or read unit size? (iirc
DVD+RW and RAID 5 arrays are examples of this.)

Pavel