[parted-devel] Resizing/moving partition with parted-3.0

[Jim Meyering]

Petr Uzel wrote:

> On Wed, Jun 08, 2011 at 02:21:15PM +0200, Jim Meyering wrote:
>> Petr Uzel wrote:
>> > I think that removing FS-related code (and most of the commands like
>> > mkfs, check,...) from parted-3.0 was a good idea, however I'm a bit
>> > surprised that resize and move commands are now completely gone. I
>> > understand why the FS-resizing code has been dropped, but I fail to
>> > see why it is impossible to do the resizing on partition table level
>> > (eventually with a warning like "I don't know how big the contained FS
>> > is and I don't care, so make sure you don't destroy your data").
>> >
>> > Is there now any other way how to resize partitions with parted except
>> > removing/recreating the partition with different size?
>> >
>> > Similar with the move command - I might be wrong, but isn't it
>> > possible just to move the partition including the contents to other
>> > offset and update partition table? IIRC e.g. NTFS would not survive
>> > moving to another offset, but in general it should IMHO work. With a
>> > sufficiently big warning it would be more useful than using dd or some
>> > similar tool (which moreover wouldn't work if source and destination
>> > overlap).
>> >
>> > Or is there some other reason why resize/move commands have been
>> > completely removed?
>>
>> Hi Petr,
>
> Hi Jim,
>
> Thanks for the reply.
>
>> I think it is important to cut the cord completely.  Leaving those UI
>> "commands" or the APIs, but with reduced functionality, would surely
>> have led some people to presume there had been no change and to end up
>> losing data.
>>
>> However, I do see the value in having FS-agnostic move and resize
>> operators.  At least the grow-in-place subset of "resize" would be handy
>> for those rare few who use parted directly.  That should be safe for
>> all file system types.
>>
>> Do you know of tools that would benefit?  Since it's possible to simulate
>> them (as you note) by removing and recreating a partition, with or
>> without an actual data move, I'd see more value in the proposition if
>> there are existing applications that require this functionality.
>
> At least libstorage, around which SUSE's partitioner is built, depends
> on 'parted resize' functionality. Clearly the FS-resizing will need to
> be moved to libstorage itself (using external utilities), but still I
> think it would benefit if FS-agnostic partition resizing could be done
> with parted.
>
> Honestly I don't know if libstorage also uses 'parted move' nor I'm
> aware of any other tool which needs it.

If it used any FS-manipulation functionality from parted,
(other than HFS- and FAT-resize), I urge you to switch.
The FS-writing code in parted was very old, probably with
many bugs in the dustier corners.

>> Of course, once you talk about actually moving partition data, it's more
>> efficient to have parted do it, especially when source and destination
>> overlap -- in which case, the naive manual approach (without parted
>> support) would involve copying all data to a third location and only
>> then writing to the destination.  Feasible, but not at all efficient.
>>
>> So, yes, I think that would be a useful addition.
>>
>> Are you interested in working on this.
>
> Yes, certainly, otherwise I would probably have to maintain parted-2.4
> in SUSE forever :)

You'll be glad to hear that someone has extracted parted's
HFS-resizing code into a separate library.
He said he'd publicize the work-in-progress soon.

That leaves only FAT-resizing to be extracted into its own
library.  All other file system types that parted knew about
were already handled by FS-specific tools packages.  If you know
of any other free FAT-resizing code, please let me know.