From owner-freebsd-scsi Thu Aug 21 16:28:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA29338 for freebsd-scsi-outgoing; Thu, 21 Aug 1997 16:28:25 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA29305 for ; Thu, 21 Aug 1997 16:28:17 -0700 (PDT) Received: from gurney.reilly.home (d30.syd2.zeta.org.au [203.26.11.30]) by godzilla.zeta.org.au (8.8.5/8.6.9) with ESMTP id JAA29949; Fri, 22 Aug 1997 09:23:23 +1000 Received: from gurney.reilly.home (localhost [127.0.0.1]) by gurney.reilly.home (8.8.5/8.8.5) with ESMTP id JAA26043; Fri, 22 Aug 1997 09:18:10 +1000 (EST) Message-Id: <199708212318.JAA26043@gurney.reilly.home> Date: Fri, 22 Aug 1997 09:18:08 +1000 (EST) From: Andrew Reilly Subject: Re: newfs on Fujitsu R640 (2k sector media) To: bde@zeta.org.au cc: freebsd-scsi@FreeBSD.ORG In-Reply-To: <199708211423.AAA13070@godzilla.zeta.org.au> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 22 Aug, Bruce Evans wrote: > I don't think it will work in any version of 2.2. (Only) > -current has some hacks to support non-512-byte sectors. Darn. Given all of the recent exhortations to the unwashed not to muck about with -current unless they were actively doing development, I'm loath to do that upgrade. Is there any chance of the relevant changes filtering back into 2.2? (I'm about to try tracking that, with CTM. Do you know whether the source from the 2.2.2 distribution corresponds to the last 30+M CTM level 0 update? Guess I'm about to find out.) > DIOCGDINFO [...] fails because there is no in-core disk label (drivers > attempt to read the label using 512-byte sectors and this doesn't work > for your disk). Thanks for that explanation. All is clear now. > `disklabel -r ...' works because it bypasses the in-core label and > writes 8K at a time. Ah. > Something like this might work for the 'c' partition only, because the > 'c' partition can be accessed when there is no label (it has to be accessible > so that the label can be written). The above error is probably caused by > the last 3/4 of the disk not being accessible because the bounds checking > routine assumes that sectors have size 512. Try using fake 512-byte > sectors (`se#512', and sector counts 4 times as large as the actual counts). Won't this be foiled when newfs attempts to write the last sector, to verify that it can, and uses a 512-byte write? I think I'll try tar'ing to the raw device for now. -- Andrew "The steady state of disks is full." -- Ken Thompson