first of all, thanks Nick for your time going through all of that. here is my answer. it is all quite i386 specific though.
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. 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 > 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? 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... 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). 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 ;-) > > 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? 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. > 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). > well, you DID take the default for that. As mentioned in faq4.html, > when working around existing partitions, CHS mode is probably easier > than sector count mode. i did. to see what it does actually. > > 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. > ok, now test your algorithm against this case: > Four partitions on a disk, laid out front to back as you would probably > assume: > 0 10G > 1 100G > 2 20G > 3 120G > > Now, delete partitions 1 and 3. > Add a partition. What's its starting sector? What if I want to > add a 120G partition? How do you override it? this is a nice example. first of all because i havent tested yet if fdisk checks for overlaps, i need to look into that. there is no need for a complicated algorithm. all fdisk would do, is simply offer the c/h/s from no. 1 as default (up to the beginning of the next partition (no 2.) or the end of the disk). if the user wants a 120G partition, he/she simply enters the appropriate values and ignores the defaults. just like he/she has to do _every single time_ in fdisk as it is now. > 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. > 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. 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"... > "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. > > fdisk:*1> p m > > Starting Ending LBA Info: > > #: id C H S - C H S [ start: size ] > > ------------------------------------------------------------------------------- > > *0: 07 0 1 1 - 8354 254 63 [ 63: 65539M ] > > HPFS/QNX/AUX > > 1: 07 8355 0 1 - 25063 254 63 [ 134223075: 131069M ] > > HPFS/QNX/AUX > > 2: A6 25064 0 1 - 29241 85 4 [ 402653160: 32768M ] OpenBSD > > > > 3: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused > > > > > > please note the ending CHS for the openbsd partition. nothing > > good can come out of these values... > > Really? I haven't seen an issue in a very, very long time, and > that was with OSs I think I'd prefer not to talk about anymore. 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. > 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. > 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. > not doing that. Plus, with modern disks, the sector counts exceed > the abilities of a standard eight digit calculator (I love using an > 80 year old Comptometer or Monroe mechanical for disk calculations), call me a rebel, but i am just fine with installing a system without a calculator and/or paper and pencil... > 2) Still has to be able to do ANYTHING possible with MBRs, even if > wrong, immoral, or against certain political party's platforms. > 3) Don't piss off the advanced users who have learned to LOVE the > power of the OpenBSD fdisk tool. > 4) Don't look to Linux as a solution, the ones I've seen SUCK (see > #3 above). > 5) Must work for all fdisk platforms > 6) Must be the ONE tool. I don't think anyone will support two > fdisk-like tools in the tree. It has to be one tool that does > everything properly. 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. either that, or remove defaults totally. so you will have more space on the floppies :p -f -- women are meant to be loved, not to be understood.
