[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#24502: [PATCH] libparted: Show partition boundaries in sectors by de
bug#24502: [PATCH] libparted: Show partition boundaries in sectors by default
Fri, 14 Oct 2016 15:43:52 -0400 (EDT)
> 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
need the default print to be compact and likely won't even need to look at it
Another and the best example of this, I suppose, would be parted's claim to
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
lvm uses sector boundaries as a guide to writing it's labels/metadata. Higher
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
information for any number of reasons. This information should be provided in
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
it can't be that bad with such a following. And the new function in fdisk,
it being something we've talked about in my group for a long while, is the
behind this patch. For the record I and my colleagues preach parted use.
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
> 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.
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
comfortable laying out the partition in s. This comes back to the user needing
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
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
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.