1 Topic by eldiener

  • eldiener
  • Member
  • Offline
  • Registered: 2013-03-18
  • Posts: 59

Topic: Allowing copy partition functionality based on used data

GParted would really be much more usable if it allowed the user to copy a partition to another place based on the used data size and not the total size of the source partition. If I have a parttion of xxx bytes size, of which only yyy bytes are being used, I should not need a destination of at least xxx bytes to copy the partition if at least yyy bytes were available in the destination area.

This situation comes up when a very large partition has much less actual data on it than its actual size. This is most often done so that the user does not have to worry about increasing the size of the partition at some future date, but wants to make the partition large enough for long term use. Backing up such a partition by copying to another disk, most often on some external drive, should not require the same sized partition area on the external drive if the actual used data in the source partition is much less than the actual source partition size.

Even if copying just the used data of a source partition to a destination partition area that is at least as large as the used data size were to be much slower than just copying an entire partition, the functionality would be valuable in the case when there is not enough room on the destination drive to copy the entire source partition, or when the user wants to save space on the destination disk. Some partition programs do allow this functionality but GParted does not. It would be great if GParted were improved to allow this functionality also.

2 Reply by gedakc

  • gedakc
  • Developer
  • Offline
  • Registered: 2007-11-30
  • Posts: 4,578

Re: Allowing copy partition functionality based on used data

If you only want to copy the data then you might create a smaller partition on the destination device.  Then without the use of GParted you can mount both the source and destination file systems, and then issue a folder and file copy command.

3 Reply by eldiener (edited by eldiener 2019-08-20 20:19:56)

  • eldiener
  • Member
  • Offline
  • Registered: 2013-03-18
  • Posts: 59

Re: Allowing copy partition functionality based on used data

It is not so much a matter of only wanting the data but of backing up a very large partiton, with significantly less used data than the total partition size, to an external drive without wasting extra space. I agree your suggestion should work, but I would need to figure out the command to use that would copy all the data. In some cases we are talking about boot data and system files, access and permissions, and that whole rigamarole can get pretty complicated to get right. That is why I suggested that GParted, or its underlying functionality, could do this, strictly based on its knowledge of partition types and data layout. The idea is that if I have a terabyte sized partition where only 200 gigibytes are actually being used I should be able to backup the partition to a 200 gigabyte area, thus saving 800 gigabytes of disk space on the destination drive. I tend to create some partitions, where I know I will be doing much intensive data processing, much larger than my present need because I then do not have to worry about the parttition filling up for a very long time if ever. Unfortunately backing up such a large partition takes a great deal of space on a destination drive, even when the actual data on the source parttition is much smaller than the total size. I can not be the only computer user that operates like this.

4 Reply by gedakc

  • gedakc
  • Developer
  • Offline
  • Registered: 2007-11-30
  • Posts: 4,578

Re: Allowing copy partition functionality based on used data

There are many ways to achieve the goal of backing up data from a larger partition into a smaller partition using GParted or other tools.

  • To copy the partition into a smaller partition you might use the following sequence of steps in GParted:  Shrink source partition, copy source partition to destination, grow source partition back to original size.  Note that there is always some risk involved in editing partitions, and one must properly handle duplicate disk identifiers (UUIDs).

  • To copy only the data (with no compression) from the source partition you might mount both the source and destination partitions and then copy the contents from the source to the smaller destination using command line tools or a graphical file manger.

  • To create a smaller backup of the data in a partition you might consider using a tool that compresses the data into a single file, such as FSArchiver.  FSArchiver is included on the GParted Live image.

This post is a response to the duplicate Copying used data

5 Reply by eldiener (edited by eldiener 2021-05-24 18:42:49)

  • eldiener
  • Member
  • Offline
  • Registered: 2013-03-18
  • Posts: 59

Re: Allowing copy partition functionality based on used data

gedakc wrote:

There are many ways to achieve the goal of backing up data from a larger partition into a smaller partition using GParted or other tools.

  • To copy the partition into a smaller partition you might use the following sequence of steps in GParted:  Shrink source partition, copy source partition to destination, grow source partiion back to original size.  Note that there is always some risk involved in editing partitions.

  • To copy only the data (with no compression) from the source partition you might mount both the source and destination partitions and then copy the contents from the source to the smaller destination using command line tools or a graphical file manger.

  • To create a smaller backup of the data in a partition you might consider using a tool that compresses the data into a single file, such as FSArchiver.  FSArchiver is included on the GParted Live image.

1) It takes much more time to shrink a partition and then subsequently expand it again than just to implement the GParted feature I suggest.

2) There may be data in a partition that needs to be copied in the exact same order as it exists in the source, such as bootup code in the very beginning of a partition. Doing what you suggest would fail miserably in such a scenario.

3) Compressing data and subsequently uncompressing data takes time, and does not guarantee that all the relevant data is being compressed.

Once again I appeal to you, or to GParted, to implement this simple feature that would make GParted much better functionality wise than it currently is. I am not trying to butter you up, but GParted is a very good program. But the inability to have it allow the copying of the data portion of a parttition to another area whose size is equal to or greater than just that data size, would make it much better. Am I really the only person who uses GParted that finds it incredibly irritating that if I have a very large size partition whose data consists of something well less than the total size I must copy it to a partition area that is equal to or greater than the size of the source partition rather than to an area that is equal to or greater than the size of the data in that partition ? Why shoud I have to waste a tremendous amount of hard disk space in that way, or got through a slow subsequent process of shrinking down my destination partition, when Gparted should be able to do it with the feature I suggest in a single quicker step. Why is this suggestion seen as being so technically outrageous when GParted already is showing me that it has all the information it needs to do this and, in fact, appears to correctly copy only the data anyway into the destination partition to begin with. In other words I do not see that GParted has to do any extra coding than it already does do, but simply just needs to allow the end-user to choose in its GUI a destination partition that is big enough for the data area of the source partition rather than the entire size of the source partition. Is there anything else that GParted actually has to do ? Is this being held back by the underlying Parted code ? Your resistance to even considering this basic improvement to GParted suggest some other difficulty other than just changing the GUI front end code to allow it, so I am really curious as a programmer what is behind that resistance. Do you actually not see how this feature would make GParted much more useful for end-users ?