Date: Thu, 28 Mar 1996 18:17:12 +1100 From: Bruce Evans <bde@zeta.org.au> To: jerry@border.com, terry@lambert.org Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: fdisk and partition info Message-ID: <199603280717.SAA18075@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>This means that in order to provide a FreeBSD fdisk program, you >must be able to determine the BIOS geometry of the underlying >drive. This is without regard for the underlying implementation >details of the fdisk program itself. >Generally, there are three approaches to solving this problem: 0) Ask the user. >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. >2) Interpolate the geometry from an existing DOS partition > table, and the known rules of behaviour for the DOS fdisk > program. Specifically, starting and ending on cylinder > boundries, etc.. Since it is possible to have multiple This is sort of what the slice code does (only for the purposes of guessing the BIOS geometry for exporting to fdisk and for putting in the default label). It also uses the known rules of behaviour for the _FreeBSD_ fdisk program/installerperson combination. It should give more weight to the FreeBSD partition(s), but this wouldn't help much because few disks are supplied a FreeBSD partition already on them. > geometries result in the same values, especially when you > have a small number of partitions (for instance, one), > this is not a 100% reliable approach -- in general, it is > so *unreliable* that the slice code was invented to replace > it. A small part of the slice code was invented to _centralize_ this geometry guessing. It's very confusing to have disk controllers BIOSes, fdisks, installerpersons, install programs, slice code and drivers all guessing the geometry. > It's possible to "help" this approach be more accurate > using the 32 bit absolute sector address, which is also in > the partition table. The problem with that is that older > FDISK programs did not generally fill out the 32 bit sector > offset correctly, so determining this information is usually > no more reliable if the offset happens to check a valid > geometry [NB: the FReeBSD FDISK should always fill these > fields out correctly in any case). The slice code _relies_ on the absolute sector numbers. It could be smarter about guessing the geometry based on the number of sectors, but its not clear what it should do about inconsistencies. Many inconsistencies are already detected, but no correction is attempted, and the warnings are disabled by default (set the kernel variable dsi_debug to enable the warnings). >3) Ask the BIOS. There are several ways to do this: >... > Such "BIOS-begging" would probably require multiple I/O's > to the disk to assemble MD5 checkums (one method) to identify > specific sectors to establish BIOS-drive-number-to-protected- > mode-driver-device-id mappings. Otherwise, you wouldn't be > sure which drive was which, and even when you knew all the > BIOS drive geometries, you couldn't match them to non-BIOS > drives. FreeBSD knows all the BIOS geometries but not the mappings. >My personal opinion is that option 3c is not an option. The reason >I believe this is that I think that partitioning should occur in a >standard framework, and it will be impossible to fit all types of I agree. >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. >To achieve this, I would suggest leveraging the devfs code. Specifically, devfs would only provide the scaffolding. >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. >2) There is no natural recognition of hierarchical ordering in > a flat name space, when in fact what is presented is a logical > on physical driver hierarchy. The n-m mapping of the graph is > too complex to deal with in a flat name space and still present > a uniform user interface. Specifically, if I have an arbitrary > device in a flat name space, am I allowed to add DOS partitioning > to it or not? My argument here is that without an easy way > to traverse the hierarchy of devices to find parents, there > is no easy answer to that question, short of iterating all > devices... I really want only one layer. Multiple layers are difficult both to implement and to use, and don't provide any significant benefits. >As for intermediate soloutions, the first problem is, as you've >identified, finding out the BIOS geometry for a given drive to >allow application of DOS disk partitioning and extended partitioning. Imagine having this problem at `L' layers for `N' operating systems :-(. The geometry information might be burried at layer L(O) for operating system O. For a practical example, consider accessing FreeBSD partitions under Linux vs accessing Linux partitions under FreeBSD. Linux would have to do a lot more work to access FreeBSD partitions because they are one layer deeper. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603280717.SAA18075>