Subject: Re: proposal for non-512 bytes/sector block device
To: Matthew Jacob <mjacob@feral.com>
From: Jason Thorpe <thorpej@nas.nasa.gov>
List: tech-kern
Date: 06/26/1997 10:20:24
On Thu, 26 Jun 97 09:09:17 PDT 
 mjacob@feral.com (Matthew Jacob) wrote:

 > Oh, absolutely there are devices that take Mode2 amounts or don't
 > have DEV_BSIZE chunks- but my point here is that until they become
 > even a relatively common exception I don't see the need for major
 > rearchitecting of Unix.

I agree with Matt, here... Basically, it's _very_ convenient to assume
DEV_BSIZE in the rest of the kernel as, basically, an abstraction.

Koji-san has caught the file system cases.  But, what about the swap
pager?  What about raw i/o?

I think it's really much more convenient to assume DEV_BSIZE everywhere
and do conversions in the actual drivers.  The conversions are relatively
simple, really.

It occurs to me that most drivers that most drivers that "do" these
conversions are actually missing one sanity check...

If you take a look in e.g. vndstrategy() (I pick that one because that's
the one I've hacked on most recently :-), there is a check for the transfer
length:

	/*
	 * The transfer must be a whole number of blocks.
	 */
	if ((bp->b_bcount % lp->d_secsize) != 0) {
		bp->b_error = EINVAL;
		bp->b_flags |= B_ERROR;
		goto done;
	}

I suppose the test should actually be:

	/*
	 * The transfer must begin on a whole block and be a whole
	 * number of blocks in length.
	 */
	if ((bp->b_blkno % lp->d_secsize) != 0 ||
	    (bp->b_bcount % lp->d_secsize) != 0) {
		bp->b_error = EINVAL;
		bp->b_flags |= B_ERROR;
		goto done;
	}

Now, if all drivers do this, then we can simplify the problem a
little, I think...

We can always make the assumption that drivers will be given addresses
and lengths in terms of DEV_BSIZE blocks.  lp->d_secsize will _always_
reflect the actual physical sector size.  Values in the disklabel will
_always_ be in terms of physical sector size.  Drivers will _always_
perform sector conversion.

Shouldn't that solve the problem?

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                               Home: 408.866.1912
NAS: M/S 258-6                                          Work: 415.604.0935
Moffett Field, CA 94035                                Pager: 415.428.6939