UDisks: partition resize/move support
Ivo Georgiev
ivo at linvo.org
Tue Nov 8 06:31:20 PST 2011
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
More information about the devkit-devel
mailing list