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
pgp8P58FSpvzy.pgp
Description: PGP signature
_______________________________________________ parted-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/parted-devel
