Date: Fri, 29 Mar 1996 10:12:25 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bde@zeta.org.au (Bruce Evans) Cc: bde@zeta.org.au, terry@lambert.org, freebsd-hackers@FreeBSD.org Subject: Re: fdisk and partition info Message-ID: <199603291712.KAA05715@phaeton.artisoft.com> In-Reply-To: <199603290733.SAA09390@godzilla.zeta.org.au> from "Bruce Evans" at Mar 29, 96 06:33:39 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603291712.KAA05715>