Note, I'm not on this list, Theo forwarded the message for me. On Tuesday, March 31, Theo de Raadt forwarded: > Date: Tue, 31 Mar 2009 20:13:22 +0200 > From: frantisek holop <min...@obiit.org> > To: misc <misc@openbsd.org> > Subject: Re: the fdisk man page and the fdisk behaviour > > hmm, on Tue, Mar 24, 2009 at 11:34:38PM -0400, Nick Holland said that > > I really don't want to ignore what you call an "exotic geometry". > > A lot of people seem to think there is something "standard" about > > what you are calling "n/255/63 geometry", but life ain't so
Ok, first we have to know which geometry we are talking about. If it is the geometry that the hardware (disk) gives us, then the 255/63 geometry is special in that it is usually prefixed with a specific number of cylinders (the number escapes me right now), which is the ATA/IDE way of telling you that the geometry is fake, and for the operating system to use LBA methods to access the disk. The other geometry is the BIOS geometry. This is the geometry that the BIOS exposes to the operating system and booting environment. This is usually the same as the disk (if possible), but does not have to be. For the purposes of the MBR and partitioning, this is the only geometry that matters. Note, on some platforms this "BIOS" geometry will be the same as the disk reported geometry always. IE: they don't have a BIOS to get in the way of relatively sane hardware. > well, the commercial sector making partitioning software seems > to disagree here. the quite popular PartitionMagic comes to my > mind. and openbsd itself had a commit in the past to show every > sd(4) disk using this very same geometry if i am not mistaken. Ok, that was the hardware geometry. Again, different from BIOS geometry in most cases where it matters. > here is another mail i sent in a looong time ago, another saga > of mine, where because of openbsd's different geometry settings > overlapping partitions and other filesystem errors manifested > themselves, no doubt because of my inability to calulate all > the numbers using a different geometry. > http://marc.info/?l=openbsd-misc&m=116475065104125&w=2 Yes, in general, fdisk(8) tries really hard to find and use the BIOS geometry. If it does not, one thing you can try to do is to boot into the /boot environment (the "boot>" prompt), and type 'machine disk', and have a look at what the geometry is for the disk you like to deal with. Then use the command line flags to fdisk(8) to set the right geometry when you're editing the partitions on the disk in question. Note, when you move a disk from one system to another, or change the disk access method (legacy, large, etc, etc), it may well cause the BIOS to change the disk address translation mechanism it will use, which *WILL* cause you issues. If it does not, you're simply lucky. > all your examples are without a doubt valid, but are they > representative of the current hard drive situation? that's > what typical means for me in this context. if you have to > hunt for these disks on ebay, they are hardly typical or > representative for me... Irrelevant. Seriously. I'm not against making fdisk better of easier to use, but it needs to be smarter than simply say "Well, 90% of disks today are this way...". If you really want to look forward, code up the relevant pieces of the GPT partitioning scheme... if you do so, and it works/etc, you'll get the benefit of picking the OpenBSD GPT UUID identifiers... :) > numeruous people stated on this mailing list that geometries > had become abstract numbers in the world of modern hard drives > and are basically useless anyway. if that is the case, i do > not see a good reason why not go with the other mainstream > operating systems and just do make with an n/255/63 geometry > everywhere (where possible). Again, most of the time that is a hardware geometry. Most modern BIOS will also use a 255/63, simply because it maps most easily to the current hardware. However, plug in a RAID card, and see it give you something different. Plug in a USB stick, and notice it getting something completely different yet again. > i havent seen hard drive's described by their c/h/s in any bios > for years (yes, i know, you probably have that old machines > as well ;-) It does not matter. Do you have Win2k on your box? Does XP touch it? Any number of OSes are going to require that the C/H/S based fields in the MBR are correct for them not to step on Open's toes. > > > violates the CAVEATS section of the man page on two counts: > > > > > > 1. the ending boundary of the 0th partition does not "end at > > > cylinder boundaries." This one is a little harder to fix. But for GPT support someone will have to put a notion of regions on disk used/free into fdisk. Once that is there, a sanity check can be made to see if the space between the current, unadjusted, end and the next cylinder boundary is free. If so, then we can round up (which would be nice). Any takers? > > > 2. the openbsd partition does not "start on a cylinder boundary > > > (head 0, sector 1), except when starting on track 0, > > > (these should begin at head 1, sector 1)." Again, same code here, just a different direction. > > > both these are cited as necessary for i386 machines... > > > > no, key word is "SHOULD", it is very far from "necessary" on > > most modern OSs. > > i think this is besides the point somewhat. ok, it is not > a problem to have partitions end/begin anywhere on the disk > (except where the MBR is) but what is the point of it? why > make your life harder? if the powers that were decided that > disks will have c/h/s, and now that disks got insanely bigger > (>8G), only the n/254/63 (n/max/max) settings are making any > slight sense (otherwise the cylinder number wouldn't fit into > a long long) then why not round the numbers up? Because you can't really be sure you're not nuking some other partition, without checking all of them. If the code is there to snarf a full disk worth of partition table entries, sort/munge them into a nice list that can be checked for overlap/etc, then I'll be willing to do this rounding. > it is like saying, ok, let's meet at 10:59:53 instead of 11:00. > all this just because "we can". even if it is not a requirement > anymore, it is just good practice. Well, actually, around here they make assignments due at 11:59:59 PM, because people are never really sure what 12:00 PM is. I realize that this may not be a problem for people on a 24 hour clock, but we've had more than one student be 12 hours late handing in an assignment... > > I really, REALLY don't like people thinking that there's something > > magic about 255 tracks per cylinder...or 63 sectors per track. Every > > time you see someone say "first partition should be offset 63 sectors" > > you should be thinking "WRONG!". > > it is true on systems with the n/255/63 geometry... > but if i said that, i meant it should be offset by the first sector > (for the MBR). I'm not sure I parse this. > > > sense if it offered me the first available lba sector with partition > > > type 0? i mean even if it doesnt want to offer any "responsible" > > > value, 0 is wrong in any case on i386, as the first offset has to be > > > at least 63... > > > > "WRONG" :) > > ok, the number should be S, as in sector. so if not usable > value is offered, at least it shouldnt offer to overwrite the MBR. You did point a problem here. Having the default value outside of the allowed range makes little sense. :) I'm asking for review and testing of a diff I've cooked up to fix this one issue. > > NOW...make it all fit on a floppy. I'm sure you just made fdisk > > bigger, not smaller, so what drivers are you going to remove from > > i386? alpha? amd64? to make it all fit again... > > i think this argument is rubbish, sorry Nick. so let's stop all > development becuase stuff doesnt fit on FLOPPIES noone uses anymore. > or i am sure they are "majority"... seriously, how long does > openbsd want to accomodate this obsolete medium? i couldnt read > a floppy today even if i wanted to! and i dont anyway. > but this is for a different thread probably. While I agree with you, I don't always get to choose the medium that I play in. I'd love to change how openbsd boots on a PC to take advantage of some newer things. About 1/2 the time the problem is that probing for these features on older machines hangs, the other 1/2 the time you need to put in weird/funky heuristics to make sure broken BIOSen don't screw you, and the other 1/2 the time it gives you a benefit. Yes, that is three 1/2's for a system that tends to work roughly 1/2 the time. > > you are confusing "If you hit enter, here's what I'm going to do" > > defaults with "here's a good value" defaults. fdisk really does > > very little to come up with "good value" defaults...and coming up > > with GOOD ones is very difficult in general. Best you just tell > > people to think it through. > > i am sorry Nick but i disagree again. look at the openbsd installer. > does it try just to give you defaults for defaults sake? it does > a terrific job of guessing stuff. the less keystrokes, the better. > computers are here to work for us, not the other way... > > i think that it is very openbsd-ish to have great default values, > wherever you look in the system. Sure, I'm all for helping you get better default values. I've simply not had the time of motivation to "upgrade" fdisk into what it should really be. If someone wants to step up and start coding things on that front, I'd be willing to point in the direction I think things should go. Hell, possibly even review/test diffs from a competent person. > if fdisk makes no effort whatsoever to help the user, it should > just stop giving defaults and wait for input. why give useless > defaults? it is not saving work, it is distracting and actually > could make some less self-confident admins question their own > input saying "but fdisk 'thinks' this could be better"... I'm quite flattered that something I wrote would get to be of such a status that something it suggests would make an admin question their own thought process. In general, the current fdisk assumes that you know enough about partitioning that you know how to help yourself. Again, if someone wants to step up and make fdisk(8) GPT aware, as well as have a better "user friendly" mode, I'd welcome that. > > "send diff" :) > > i will definitely try to come up with something. > > what people dont realize sometimes that yapping about and not giving > patches is a sign of "wanting something" but "not giving back". i > echo my ideas on the mailing list because if any of it is usable, a > developer could make it happen probably 100x sooner, or of finally i > get my sh*t together it is just flatly refused. life is too short for > that. Life... yeah, used to have one. :) > nothing good if a year later you want to add a 4th partition with > a different program than openbsd's fdisk, on a system that perhaps > detected the disk with a different geometry... > see my let's meet at 10:59:53 argument. If the disk is detected with a different geometry (different bios/etc), all bets are off anyways. Various programs out there will try to infer a usefull geometry, but they will screw up. If they manage to make it work, it's an accident... > > yeah, If you can make a really small change to fdisk to get it > > to round to nearest cylinder boundaries in THIS kind of use, I'm > > all for it. But, needs to be over-ridable, as even though they > > may not be recommended, they are valid. > > again, there is nothing to override Nick. you simply dont > take the defaults but enter your own values. What this needs is for fdisk to read all MBR/partition entries on a disk, sanity check them (loops, overlap, etc), complain/abort/fix/advise when things are not sane. Then, once you have that, what is needed next is to check these (all, even user supplied?) suggested values to make sure that you're not stepping on the head/tail of another partition when you're rounding up (down). Note, if you have this information, you could then create a very simple interface for non-power users. You can then search for "create a 20G openbsd partition", and if you find the space, you can create the right type of partition (rounded/etc) with minimal input. This will also need to be there for GPT support. > > A very long time ago, I posted a somewhat similar rant to this same > > list. I got a very polite private message from Toby, saying, "Ok, > > I'm tired of these complaints, what would you do differently?" and > > to be honest...I never came up with a good answer. > > i think i highlighted a couple of issues with very easy patches. esp. > for much more skillful person than i am, e.g. Toby. Ugh. Ok, yes, I could do it. But honestly, I don't care to. The last time a list bitched and moaned for an improvement of a particular system, I spent a considerable amount of time implementing such. When I asked for tests of the system a while later, I had 6 people test. Six. Out of the 50+ requests for the essential feature, *SIX* tested. So, now you would love it if fdisk was better. So would I. But, I'm not going to expend any energy on this, and then have 1/2 dozen people test on a dozen machines, a feature that has potential for serious data loss if there are any bugs in it. The actual code is not hard. It's on the level of what a 2nd to 3rd year CS student is capabale of. I'm just tired of being the one that has to chase enough variety of machines/people/etc to do enough different types of tests, with enough variety of other partition munging OSen to have decent test coverage. Someone else can step up and do this testing. And since the coding is fun, I'll leave the coding for them as well as an incentive. :) > all i want is saner defaults. they are defaults because they > dont have to be accepted, the user is free to enter anything else. > so none of my suggestions take away any freedom from any power user. With respect to getting a default value outside of the allowed range, I agree with you. It makes more sense to give you something that is at least valid. There is a diff out to do so. --Toby.
