Date: Fri, 2 May 1997 08:28:01 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, gibbs@plutotech.com, sos@freefall.freebsd.org Cc: freeBSD-arch@FreeBSD.ORG, freeBSD-scsi@FreeBSD.ORG Subject: Re: cvs commit: src/sys/scsi sd.c Message-ID: <199705012228.IAA29072@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>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). >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. >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. >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. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705012228.IAA29072>