On Mon, 7 Jun 1999, Chuck Silvers wrote:

> (3) change DEV_BSIZE to 1, and make b_blkno a 64bit field (possibly by way
> 	of changing "daddr_t" to a 64bit type).
>     advantages:
> 	also solves the problem in a natural way, with much less code
> 	change than (2).  most code should work as-is.
> 	supports devices larger than 2^40 bytes (though this is also true
> 	if we make b_blkno 64bits with the existing DEV_BSIZE).
>     disadvantages:
> 	though this change to the interface is much less drastic than (2),
> 	it could still involve needing to "fix" some code which is working
> 	with the current DEV_BSIZE.
> 	the lower 9 bits of b_blkno will be wasted for most uses, since
> 	most devices and filesystems assume they would be 0.
> 	64bit b_blkno will cause extra overhead for devices that don't
> 	need it.
> 
> 
> 
> I propose option 3 as the best solution.  it fully supports devices of any

The problem with solution #3 is that since sub-block accesses to some
block devices such as SCSI disks are not possible they may cause the
device to lock up.  This needs to be prevented somehow, and if you go
with #3 you need to specify how. Solution #2 handles this more gracefully.

=========================================================================
Eduardo Horvath				eeh@one-o.com
	"I need to find a pithy new quote." -- me