frantisek holop wrote: > first of all, thanks Nick for your time going through > all of that. here is my answer. it is all quite i386 > specific though.
You have to remember, the OpenBSD project doesn't have that luxury. These guys bust their butts to keep OpenBSD clean and 100% functional on 17 platforms, PLUS whatever is coming up in the future. fdisk kinda started out as an i386 tool (a bad and complicated way to do a simple task, but that was how the IBM AT spec'd things out), but a lot of new platforms use it now, too, and that is likely to continue as a lot of new platforms seem to be designed by people who think the IBM AT way is The Way to do things... > 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 > > 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. I've seen a tremendous variation in sd(4) geometry myself... Not just on i386, not just OpenBSD...but also SPARC systems running Solaris (one computer, two very very similar drives, totally different geometries. I'm not even going to try to pretend to explain that one, or the fact that if one dd's over the first meg or so of disk from one to the other, the recipient changes geometry to match the source...) Anyway...keep in mind the goals of OpenBSD's fdisk and the commercial i386-centric systems are quite different. I think a degree of disagreement is fine here, and in fact, since I've used OpenBSD's fdisk to fix or customize commercial disk layouts before, I'm glad for it. > 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 looking back at that, I see a few clues of issues that are potentially completely unrelated to geometry, and a few things that might be related to fixed bugs. Good detail provided, though. :) >> simple. Not at all. First of all, there are a lot of non-i386 >> and non-amd64 systems that use fdisk, and a lot of very usable >> machines for OpenBSD are, as you put it, "from the history books". >> >> Without looking very hard, I found these "exotics": > > yes, but are they running -current? hey, if I'm not running a relatively fresh -current on EVERYTHING I've got, Theo's gonna hurt me, and hurt me badly. :) (I keep a few machines back at prev. -release to test the upgrade instructions I write, but in this cycle, even several of those ended up being -current, too) > and most importantly, > would you call them "typical", as in where typical means: > > typ-i-cal, adj. > 2. Of or relating to a representative specimen; > characteristic or distinctive. > > 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... For IDE drives, it's the computer, or more accurately, the computer's BIOS (or the BIOS on the card or ..), not the drive. When it comes to i386 systems, I'm torn between saying there isn't much exotic...and there isn't much typical, either. Nothing I showed was really strange, at least for its vintage. All of it was picked to show oddities. Several things shocked me, like the machine with SATA and IDE, where the IDE showed as you expected...and the SATA showed up looking like a very old pre-LBA system..in spite of being attached to a nearly new SATA card. > 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). On modern LBA systems, yes, the disk is just a sequence of sectors. However, where it will bite you is with systems with buggy LBA BIOSs or non-LBA BIOSs...and those, you will probably need to be precise. And then, we would probably have to have two fdisks, one for i386 and one for everything else...for a non-reason. > 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 ;-) a couple. for really, really large values of "couple" :-/ HOWEVER, they do exist. And, there are a lot of non-i386 systems with different rules. AND if you take a drive out of a n/255/63 system and put it in a m/240/63 system, you expect it to Just Work. All this stuff violates the expectations you have. >> > 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." >> > 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)." >> > >> > 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? did you notice my 1.5TB SATA drive I gave an example of? (it shocked the heck out of me, I can assure you). IF we do anything that breaks a lot of these old systems, I'd like to see just eliminating all reference to CHS, and make it starting sector, ending sector, size in sectors. Done. Alignment? Doesn't matter to OpenBSD. That would break all the CHS systems...I don't want to do that. It might break some non-i386 systems, I don't want to go through that testing process. > 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. Go ahead, align it however you want...but by your analogy, my watch has a second hand (WTF? I've got a non-digital watch? I had an LED watch back in 1977...and now I got a non-digi? It DOES use batteries, though), and I want to have it. I don't want a watch that only tells me about every minute or every five minutes or half hour. ... >> > 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. interestingly (to me, and probably no one else), I tried an i386 install with a offset of...2. Worked fine. Can't promise it would work with all OSs, and certainly not with all boot loaders (some of which assume there is nothing for 62 sectors...) ... > this is a nice example. first of all because i havent tested > yet if fdisk checks for overlaps, i need to look into that. it doesn't. :-/ I can think of a really wacko app for this, not sure it would work and with a little foresight, the need wouldn't be there...but a small part of me is thinking the ability could be handy. A larger part of me is in the process of beating the snot out of that little part of me, and most of the rest of me is sitting back, watching the carnage and thinking, "he had it coming". ... >> 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. This isn't just my argument..this is OpenBSD policy. There aren't too many things I'll claim the right to state OpenBSD policy on, but check the commit messages on RAMDISK: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/i386/conf/RAMDISK Floppy installs aren't going away from OpenBSD any time soon. OpenBSD works too well on too many otherwise useless systems. Besides, it keeps the install process lean and efficient to have a really small least common media. (Had to do a few Solaris installs recently. There's a good example of what goes wrong when you figure you don't have to keep your installer lean. Could have had completed an OpenBSD install by the time the Solaris installer had loaded...java??) >> 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'm not going to deny that the fdisk program can be improved. ... >> "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. Hey, I beat you to whining about fdisk and disklabel by probably almost ten years. :) And actually, a lot HAS improved since then, in small, incremental ways. LBA made life a LOT easier. :) I think most the developers wouldn't mind seeing a smoother fdisk program...as long as it fit all the other criteria that a good fdisk program needs to fit. Talking about it from a x/255/63 and i386 perspective, however is not a productive starting point. There is way, way too much else in this very complicated world of small computers... ... Nick.
