bug#24502: [PATCH] libparted: Show partition boundaries in sectors by default

[John Pittman]

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.