Date: Fri, 2 May 1997 08:49:56 +0200 (MEST) From: Søren Schmidt <sos@ravenock.cybercity.dk> To: bde@zeta.org.au (Bruce Evans) Cc: bde@zeta.org.au, gibbs@plutotech.com, sos@freefall.freebsd.org, freeBSD-arch@FreeBSD.ORG, freeBSD-scsi@FreeBSD.ORG Subject: Re: cvs commit: src/sys/scsi sd.c Message-ID: <199705020649.IAA16854@ravenock.cybercity.dk> In-Reply-To: <199705012228.IAA29072@godzilla.zeta.org.au> from Bruce Evans at "May 2, 97 08:28:01 am"
next in thread | previous in thread | raw e-mail | index | archive | help
In reply to Bruce Evans who wrote:
> >We need to really think about how we want to handle media with block
> >sizes greater than DEV_BSIZE. Some questions to answer are:
>
> disklabel.h says that the sizes in the label are in "sectors", and
> I think it is best to use physical sectors in labels and in-core
> slice tables.
>
> >1) What should sd and other devices drivers "see" by the time they receive
> >the I/O? Should b_blkno always be in terms of the logical block size of
> >the device or should the device driver be responsible for scaling?
>
> Note that b_blkno is normally not used after dscheck(). dscheck() does
> conversions as well as checks, leaving the final block number in b_pblkno.
> It's probably best for b_blkno to always be in DEV_BSIZE units and
> b_pblkno to be in terms of the physical block size. This seems to be
> the case in sd.c now. b_blkno is scaled to physical units so dscheck()
> returns b_pblkno in physical units. b_blkno is scaled back to logical
> units and b_pblkno is sent to the controller. I think b_blkno is only
> used again if there is an error (diskerr() uses it).
This is essentially what is being done now, just its code inserted in
sd.c instead of generically in dscheck(). I think the authors did this
to do it with as little impact as possible. The same thing is done in
od.c (it was there allready, they just made it work).
This ougth to be pretty easy to do. I'll take a plounge at it as I
guess I'm the only one with those odd disks :)
> >2) If we decide that it really should be in terms of the logical block size
> >of the device, what consequences does this have on information in the
> >disklabel and how it's used by other areas of the kernel?
>
> No consequences, I hope. The kernel can continue to use 512-byte blocks
> except in labeling code and drivers.
There allready is code in place to handle this, also iin fdisk & newfs.
> >3) What features do we want to support? Do we want to support the ability
> >to 'dd' an image from a 512byte sectored device to a 1k sectored device
> >and have it work? If so, what constraints are needed? (disklabel has
> >the larger block size even on the smaller sector sized disk? or is it just
> >that your frag and fs block sizes need to be in sync?)
>
> I think that this is too hard to be worth supporting. It can't work in
> general, because the source partitions might have a size that is not a
> multiple of the target block size.
No, lets not get into that...
> >4) If we want to have partitions with the only constraint being that they
> >begin and end on a sector boundary, what else in the system needs to change
> >to allow this? How does this affect 2 and 3?
>
> You also need to constrain file system fragment sizes to a multiple of
> the sector size for a simple implementation. I think only sizes of 512,
> 1024, 2048 and 4096 are practical.
Yes, this is also nessesary for the current model.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team
Even more code to hack -- will it ever end
..
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705020649.IAA16854>