[parted-devel] [rfc] SSD partition alignment
jim at meyering.net
Sun Feb 22 15:23:47 UTC 2009
Daniel J Blueman wrote:
>>> What's (at worst) 128KB slack in partition layouts, when we already
>>> skip the first 63 sectors anyway?
>> If that were the only cost, we'd switch right away.
>> However, parted's code is very fragile, and changing how it handles
>> constraints/alignment seems like it'd be very risky. Why go there
>> if it's not absolutely necessary? Besides, the functionality I think
>> you want (to make the process convenient or mandatory) belongs in a
>> higher-level tool.
> Yes, perhaps Matt Domsch's work is on the right lines, or no?
Two people replied to that message with questions and comments,
but as far as I know, Matt has not answered.
Besides, as you probably already realize,
I think a low-level tool like parted must not enforce such
alignment requirements. Sure, maybe an option to enable it,
with a user-specified value, but even that has only marginal value,
yet probably has high cost/risk.
>> If the programmers and tools invoking parted cannot be bothered to
>> do a little modulo arithmetic and be aware of alignment, then they
>> shouldn't be choosing partition boundaries in the first place.
> Agreed; though it seems sensible to integrate as much of this into
> libparted and ensure the applications use the constraints, rather than
> duplicate the work in all the users of libparted:
> $ apt-cache rdepends libparted1.8-9
> [trimming list]
The difficulty is in finding a _safe_ way to do that without
breaking API compatibility.
Please give an example of what you might like to integrate.
Adding new APIs is a lot easier than changing existing ones,
so determining recommended alignment might make sense.
However, adding an option to let parted use that alignment value
(i.e., in a round-to-multiple-of-$N operation in the guts of the
partition-creation code) might be tricky.
More information about the parted-devel