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

[Petr Uzel]

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.

> 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 :)


Petr

--
Petr Uzel
IRC: ptr_uzl @ freenode
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/parted-devel/attachments/20110608/679d188b/attachment.pgp>