> (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.

3) gets my vote as well. It's the most flexible. Blocksizes are a matter
of the device drivers anyway, the higher-level code should not impose
any restrictions on them. Well, as few as possible, anyway.

- Frank