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