Date: Fri, 29 Mar 1996 18:33:39 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, terry@lambert.org Cc: freebsd-hackers@FreeBSD.org Subject: Re: fdisk and partition info Message-ID: <199603290733.SAA09390@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> 0) Ask the user. >Hee hee. I will cop out and say "I meant 'solving this problem >correctly'"; an indirect reference through a flawed user gets >you a flawed answer. 8-). Well, at least for wd drives, at least for BIOSes from a few years ago, the user or dealer had to tell the system the geometry by typing it into the BIOS setup. It's annoying to have to type in the data twice, but not hard. >> >1) Assume the geometry is translated, and that it is >> > 1024/64/256. This is what the current FreeBSD slice >> > code does, much to the consternation of those of us >> > who own WD1007 or other non-translating controllers. >> >> No, it doesn't do anything like that. Read the code. >If you will reciprocate and install a machine with a WD1007 with >factory jumpers, I will be pleased to do so. 8-). 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. >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. >> >Other types of partitioning, specifically, DOS Extended partitions, >> >BSD disklabels, Solaris disklabels, SVR4 slicing, OSF disklabels, >> >etc. etc., should all be manageable with a single tool, in my opinion. >> >> I disagree. You'll end up with support for 101 different OS's in one >> program. >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. >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. >For instance, a disk with a DOS partition table with a DOS partition >on P1, a BSD partition on P2, and a DOS extended partition on P4, >with the DOS extended partition containing a DOS logical partition >(drive), and the BSD partition containing slice 'a' (ufs), slice >'b' (swap), and slice 'c' (ufs) whould do the following: >CONTROLLER 0 probes for devices >[too much detail deleted] Will the mail^H^H^H^Hprobe finish this year? :-) >> >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. >... No time to comment :-). Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603290733.SAA09390>