From owner-freebsd-hackers Fri Mar 29 09:15:24 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA02650 for hackers-outgoing; Fri, 29 Mar 1996 09:15:24 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA02641 for ; Fri, 29 Mar 1996 09:15:21 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA05715; Fri, 29 Mar 1996 10:12:25 -0700 From: Terry Lambert Message-Id: <199603291712.KAA05715@phaeton.artisoft.com> Subject: Re: fdisk and partition info To: bde@zeta.org.au (Bruce Evans) Date: Fri, 29 Mar 1996 10:12:25 -0700 (MST) Cc: bde@zeta.org.au, terry@lambert.org, freebsd-hackers@FreeBSD.org In-Reply-To: <199603290733.SAA09390@godzilla.zeta.org.au> from "Bruce Evans" at Mar 29, 96 06:33:39 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > I did. The factory jumpers on my WD1007 default to the right values > for FreeBSD: translation enabled and no spare sector. This makes it > behave much like an IDE drive so there are no problems. You have lucked out, then. The factory defaults from AT&T/NCR are "sparing enabled". Mostly because the original SVR4 code's soft bad sectoring sucked. 8-(. > >Actually, looking at the code, I see an assumption for Adaptec; > >in fact, a 1740 has two possible translation modes. 8-(. > > I don't see any such assumption. I have 3 SCSI controllers: U34F, > BT445C and SC200. I've only used the U34F with 64/32 geometry. > The BT445C and the SC200 work with assorted drives in assorted > translation modes giving 64/32, 128/32 and 255/63 geometries. What happens if you turn of translation on the things? (yes, I know this is not a possibility for Adaptec). > >No; that's the beauty of it. You don't put the intelligence in the > >program. You put it in the logical-to-physical drivers as callable > >ioctl()'s, and you either demand-load, or compile-time select the > >types of partitioning you want to allow. > > >The program deals with a generic class of ioctl()'s and only a > >rough understanding of device hierarchy. > > The DIOCGSLICEINFO and DIOCGDINFO ioctls already give the logical to > physical mapping for all logical drives known to the system. Things > would be much simpler if BSD labels weren't supported and DIOCSLICEINFO > returned all the info. Things would be much more complicated if the > foreign labels were supported like BSD lablels or if there were more > layers. Please look at the "pseudo code" partitioning program I just posted in this thread... > >Basically, if your kernel can understand that type of partition, > >then it can manipulate it. The code overhead is relative small > >compared to the existing requirements for read/status/device-nodes. > > Not true. Reading labels is much easier than creating them. There is > a whole lot of code in the kernel to validate and write BSD labels. True. But I think the validation phase is anonymous. That is, I think the same engine can be used regardless of the partitioning scheme, so that the code can be shared between all classes of logical devices that divide up disks (ie: no overlap, contiguity, and so on). > >> >1) The hierarchy could get large fast. For instance, a device > >> > >> No kidding. There are already about 512+64 possible devices for the > >> slice and partition layers. > > >Right... that's why you would use directories for population. > > Try explaining it to a user who thinks he has one disk. How does the same user deal with having a "C:" and "D:" drive on his DOS box with one disk without going into mental-meltdown? He handles it because there's a front-end program and he doesn't have to deal with devices at the INT 13 device ID level. UNIX systems export the moral equivalent of INT 13 device ID's (0x00 -- floppy A:, 0x01 -- floppy B:, 0x80 -- disk C:, 0x81 -- disk D:, etc.). The confuse comes because the user doesn't have a nice, clean, unified view of logical devices in UNIX (like he does in DOS). NB: Windows 95 doesn't fix this for DOS: there is no grpahical partition editor: Microsoft screwed up the implementation of the "IFSMgr_PNPEvent"; they assume a different number of things on the satck on entry and exit, so the routine is useless, and even if you corrected it, the PNPEvent handling is broken -- you can't partition something and have the newly created logical device "arrive". Hence Windows 95 users are stuck with the same old scruddy fdisk in a DOS window, and rebooting 4 or 5 times. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.