Hi Phil, > Kickstart isn't the typical intended user of parted, and if it wants > sectors it can request them.
I didn't claim it was, I was using it as an example to show that users don't necessarily need the default print to be compact and likely won't even need to look at it at all. Another and the best example of this, I suppose, would be parted's claim to fame, the script function. If you're running things from the command line ,or even more so, from a script, users do not generally print after creation. >Yes, seeing the exact sectors is sometimes useful when troubleshooting, >and you can easily request that, but most of the time people people >don't need to be concerned with sectors and prefer to work in gb, which >is why that is the default. The lvm user interface also does not >normally care about sectors. Seeing sectors is always useful, not sometimes. It's GB or MB (more and more these days TB) or any higher level measurement that is only sometimes useful. And if I'm not mistaken, lvm uses sector boundaries as a guide to writing it's labels/metadata. Higher level measurements are only useful with creation and whole disk size printing. >How do you figure? If I want a 10 gb root partition and a 100gb home >partition, I tell parted to make a partition starting at 1m that is 10g >long and another starting at 10g and is 100g long. When I print the >table to check what I have done, I expect to see 10g and 100g, not >whatever that works out to in sectors. This is the one and only argument I could think of for keeping print at default compact. But the user can as easily add a 'u GB' or any other unit as they can a 'u s'. Further, if a user comes to the parted tool to create, they will specify the unit in almost all cases. I have never seen, in my working with admins and the like, a case where they do not. However, if they come to the parted tool using the print command, they are looking for information for any number of reasons. This information should be provided in the exact form of sectors. We should not choose for them how exact the information should be. This is very different than parted automatically choosing the alignment because there is no inquiry into the partition structure by the user going on in that case. > fdisk has always had a poor user interface. One of the design goals of > parted is to be more user friendly. Then why do people cling to fdisk like grim death? Sure it's ingrained behavior, but it can't be that bad with such a following. And the new function in fdisk, along with it being something we've talked about in my group for a long while, is the motivation behind this patch. For the record I and my colleagues preach parted use. That's why I'm here. :) > Parted should automatically handle alignment without you needing to do > it manually. I'm not saying it shouldn't. This is regarding printing, not creation and auto align. > By correct I assume you are again referring to alignment, which again, > you shouldn't need to worry about. By correct I meant in the correct spot in regards to whatever you were fixing. In regards to this, the fix should be as exact as the original layout, which is in sectors. If I lost a surrounded partition from 745G to 1.2T, I would not feel comfortable just laying out a partition by specifying those values and we should not expect users to either. I would however feel comfortable laying out the partition in s. This comes back to the user needing information outside of 'did my initial creation do what i thought'. >I disagree. A good tool should free you from needing to do mind numbing >calculations and worry about the minutia and just do the right thing for >you. We're talking about admins and other power users here, not novices. Additionally, by and large, linux users are more adept to this type of material than users of other operating systems. These people know well enough what they're doing to use this type of information to their advantage, and as I mentioned earlier the parted -l would allow an easier exchange of detailed information between users. I know this seems like a big change as it is very front-facing, and it seems to go against a lot of work that has been done, but in reality it doesn't. It is just an adjustment that aligns more closely with the basic difference of what is needed during an initial partition creation and what is needed on a day to day analysis basis by users. Compact just is not as useful in the print function as sectors.
