Subject: Re: non-512-byte-sector devices vs. UBC
To: None <email@example.com>
From: Ignatios Souvatzis <firstname.lastname@example.org>
Date: 06/07/1999 20:46:09
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.