Jim Meyering <jim@xxxxxxxxxxxx> wrote:
> Hugh Brock <hbrock@xxxxxxxxxx> wrote:
>> Todos:
>> Investigate gparted, one of the partition management tools we already
>> have (apis? remote accessibility?) (I believe Jim Meyering volunteered
>> to take a look at this?)
Recently, I've been spending a good bit of time getting to know and
improve GNU parted:
http://git.debian.org/?p=parted/parted.git;a=summary
Note that GNU parted builds the command-line tool, "parted", and an
underlying library, libgparted, while "gparted" is a full-featured
GUI-based tool that depends on lots of libraries (including libgparted)
and command-line oriented tools.
Currently, other than my work on the trunk and David Cantrell's work on
the upcoming parted-1.8.3, not much is happening on the Parted development
front, afaik. Well, there have been a few patches to add FreeBSD support.
Note that the previous parted maintainer stepped down in mid-January.
Some of the things I've done: modernized parted's build infrastructure,
made some of its interfaces "const correct", and tracked down the source
of the Gparted-ISO/CD segfault. That the latter led to my finding
three buffer-overrun bugs was a big surprise. I had the impression
that parted was more mature. I don't know the history, but expect it's
just fall-out from a recent change to let parted handle larger-than-512B
logical sectors. In its defense, Parted does issue a big warning when
it has to deal with a disk having a logical sector size of 2048:
... Not all parts of GNU Parted support this at the moment,
and the working code is HIGHLY EXPERIMENTAL.
Parted has what looks like a reasonable testing framework, but it is
suffering from bit-rot: all tests fail, though it might be easy to fix.
Actually bit-rot is a problem with another big part of parted: since
most of the fs-specific code is from snapshots of other projects,
it is probably old. Both removing that fs/ code (and replacing with
uses of external libraries, where possible) and adding unit tests are
high priority.
Another pretty high priority item seems to be adding LVM support. Several
people have expressed interest in the last few months. However, there
is no API at all for it[*]. I've heard that Alasdair Kergon is amenable
to the idea of someone else adding a real API, and that there are already
some requirements. I've just begun to look at device-mapper and lvm/lvm2.
How important do you guys think having LVM support will be to ET projects?
And when will you need it?
FYI, as for my plans, top of the list is getting some parted tests running
(and passing), and then checking in fixes for the few problems I uncovered
but haven't yet been able to test. Then I'll finish reviewing the public
interfaces and fix some link-related problems (among other things, libparted
maintains some static state). Then I'll look into LVM.
Jim
[*] liblvm2cmd, a wrapper around the command line tools, doesn't count :-)