UDisks: partition resize/move support

[Georg Grabler]

Just take a practical example: a graphical partition manager (gparted,
qtparted, any partition manager in any linux installation program etc.).

There you need to implement the partitioning using parted, most likely done
using the operation stack parted provides, need to know about partition
flags, need to convert data types and do your own structures representing
the partitions in the UI etc. This is not really trivial, and can result in
a more or less heavy implementation. Next to that, you need your program to
check which file systems are supported (ext2/3/4, brtfs, xfs, ...), and
need to implement the different options to check, format and handle each
file system, not mentioning that the implementations on different platforms
for the filesystem tools do not always match looking on the provided
options.
Now, every partition manager written nowdays does that on it's own, so we
have dozens of different implementations of partitioning and file system
formatting.

UDisks should put this into literally one place where this kind of things
are developed, and the end user application only makes use of the
functionality udisks provides and "shows" the results. In my case, my
implementation for a partition manager (Tribe) went down from ~6000 LoC to
~1200 LoC (ONLY the partitioning part, without the UI) using UDisks over
DBus. And my implementation is not close to the length or perfection of
other implementations (paradus has a ~13.000 LoC implementation, debian
~9.000 LoC, etc.).

You still need operation stacks and similar, but you don't need to care
about all the low-level calls and what-is-supported and what not, the
permission handling (which udisks does using a quite nice policykit
implementation).

As a system administrator you probably will not need that in first place,
but it easens up the work of application developers in need of
disk/partitioning stuff [a lot].

Best regards,
Georg

On Tue, Nov 8, 2011 at 3:34 PM, Ivo Georgiev <ivo at linvo.org> wrote:

> I think a D-Bus interface is much easier to implement in a program that
> needs to handle anything partition related. Plus, it's all a unified
> interface - getting data about devices, partitions and/or modifying them.
>
>
> In general, the problem of resizing file-systems and partitions is
> something that, in Linux, has no unified solution, To
> resize/check/create/modify a file-system you need to call the specific tool
> for the given FS. This is really tedious and annoying to implement,
> considering it is already implemented in other programs but the code is not
> reusable. When it comes to modifying the partition table itself, libparted
> is difficult to use. Having a unified system interface to do everything
> related to storage devices is really the way to go.
>
> By the way, how about implementing a Resize method in the device class if
> it is resizeable that abstracts Filesystem.Resize and Partition.Resize and
> calls them in the valid order or throws an error if the given dimensions
> overlap with other partitions.
>
> Also, a property that defines if the partition+filesystem can be
> shrinked/expanded/moved according to the FS type (e.g. XFS cannot be
> shrunk) would be nice. Also, that property should be influenced by which
> external tools are available (e.g. if e2fstools are not installed, this
> property of all partitions with ext* type will indicate you cannot modify
> them).
>
> On 08.11.2011, at 01:44, walt <w41ter at gmail.com> wrote:
>
> > On 11/07/2011 11:56 AM, David Zeuthen wrote:
> >
> >> ...
> >> The current code in master simply shells out to the parted(8),
> >> sgdisk(8) and sfdisk(8) tools to do the heavy lifting. I expect the
> >> implementation of Partition.Resize() to do something similar...
> >
> > Hi David.  I'm very familiar with parted and friends because I use them
> > often, but I'm completely confused by why udisk should get involved with
> > those tasks when I (the user) can use the same tools directly.
> >
> > What is the problem that udisk would be solving by supplying the same
> > functions?  Who whould be using udisk to do those tasks instead of
> > using the tools directly?  I ask as a udisk outsider, so a very short
> > answer would be more than sufficient :)
> >
> > Thanks.
> >
> > _______________________________________________
> > devkit-devel mailing list
> > devkit-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/devkit-devel
>
> _______________________________________________
> devkit-devel mailing list
> devkit-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/devkit-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/devkit-devel/attachments/20111108/3d3f9403/attachment-0001.html>