On Mon, Jun 07, 1999 at 08:22:38AM -0700, Eduardo E. Horvath wrote:
> 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.

We can move this check to the bounds_check_with_label routines, or to the
drivers themselves. After all, the drivers (e.g. sd) are the ones who might
know what is really the case.

	-is