From owner-freebsd-scsi Thu May 1 16:13:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA24189 for freebsd-scsi-outgoing; Thu, 1 May 1997 16:13:53 -0700 (PDT) Received: from pluto.plutotech.com (root@pluto100.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA24166; Thu, 1 May 1997 16:13:38 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.3) with ESMTP id RAA24125; Thu, 1 May 1997 17:13:03 -0600 (MDT) Message-Id: <199705012313.RAA24125@pluto.plutotech.com> X-Mailer: exmh version 2.0beta 12/23/96 To: Bruce Evans cc: gibbs@plutotech.com, sos@freefall.freebsd.org, freeBSD-arch@FreeBSD.ORG, freeBSD-scsi@FreeBSD.ORG Subject: Re: cvs commit: src/sys/scsi sd.c In-reply-to: Your message of "Fri, 02 May 1997 08:28:01 +1000." <199705012228.IAA29072@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 May 1997 18:11:20 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>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). So dscheck should do the conversion based on the sector size in the disklabel? >>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. Does any of this discussion affect the vn driver? What about being able to create an ISOFS on a hard drive? Do we only support that via vn? >>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. So newfs needs to consult the disklabel and ensure that the frag/block size is a a power of 2 multiple of the physical sector size in the disklabel. >Bruce -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations ===========================================