[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 12:52:00 -0400
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
On 10/14/2016 10:25 AM, John Pittman wrote:
> At initial creation people will still use whatever unit they care about,
> whether it be GB, MB, or TB (or sectors). But they'll be specifying the
> units by hand.
> Likely not even using the print function until the end and possibly not at
> all (creation
> done through kickstart)
Kickstart isn't the typical intended user of parted, and if it wants
sectors it can request them.
> This patch is not about creating however, it's about printing, which
> indicates a need
> to "look back" at the partition structure. Whether admins are
> troubleshooting performance,
> a missing partition, a misaligned partition, the need will be to make
> adjustments in sectors,
> therefore the need will be to view the boundaries in sectors. The operating
> system and the
> software layers atop it (clustering & lvm for example) care about sectors and
> so should we.
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.
> To have the precursory knowledge to know that one needs to manipulate a
> partition boundary
> also suggest the knowledge to know that the manipulation should be done in
> sectors. All
> else will bring unexpected results. The majority of users of this tool are
> for servers, not desktop users (desktop users would likey use a gui tool)
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.
> The latest fdisk packages print in sectors by default. They do however,
fdisk has always had a poor user interface. One of the design goals of
parted is to be more user friendly.
> to my patch proposal, provide the whole disk size in B, s, and some other user
> friendly unit. My colleagues and I are all in linux storage
> engineering; my claims regarding alignment with the needs of administration
> are based on
> direct observation of everyday administration issues as seen by our customers.
Parted should automatically handle alignment without you needing to do
> I'd argue the opposite, if someone is thinking about partition boundaries,
> would not be thinking about what MB boundary it falls on, at least not for
> They'd realize quickly that they need sectors to have any certainty that the
> changes they are making are correct.
By correct I assume you are again referring to alignment, which again,
you shouldn't need to worry about.
> For whole disk size the compact print is great, that's why I've included it
> in the patch,
> but for boundary location printing, sectors should be used are are far more
> Additionally, we should, as people providing/supporting these
> products/services promote
> sector use, not steer users away from it.
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