GNOME Bugzilla – Bug 663806
Cannot copy XFS filesystem to new smaller partition anymore
Last modified: 2011-12-13 17:42:14 UTC
Functionality was added to copy XFS filesystems to a smaller partition (effectively allowing the user to shrink an XFS partition by copying to an intermediary partition then copying back). From the features page (http://gparted.sourceforge.net/features.php) it mentions: "Although it's not possible to shrink an xfs file system directly, you can shrink it using GParted's copy functionality." However, there is an extra check before the copy procedure that appears to have been added to safeguard people from copying large partitions to smaller parts of the disk. For XFS partitions, this was supported (so long as there was enough space for the data, the partition size doesn't matter). When attempting to copy a large XFS partition to a smaller area of the disk (which is still big enough to hold the data) it results in the error: "the destination is smaller than the source partition" I've discussed this on the forum with gedakc, who tells me this is a bug. Manually executing the steps within xfs::copy() work fine. The check itself lives within GParted_Core::copy(). You can see the thread here: http://gparted-forum.surf4.info/viewtopic.php?id=15712 Tested with: GParted 0.9.1 --enable-libparted-dmraid Libparted 2.3 Thanks steveybaby2
Thank you steveybaby2 for following up on this problem in the forum and then creating a bug report. :-) An enhancement to re-enable copying to a smaller XFS partition has been committed to the Gnome git repository for inclusion in the next release of GParted. The relevant git commit can be viewed at the following link: http://git.gnome.org/browse/gparted/commit/?id=38aab666b47d0d66fe41ebdf48899d099230c02b If you are able to test this patch it would be much appreciated. You can learn how to compile GParted from the git source code at: http://gparted.org/git.php
Thanks for the change - I've done some testing and can confirm that the copy and paste of XFS partitions works successfully when the destination partition is smaller than the source. I also tested copying an ext4 partition and can confirm that the check still takes place and prevents copying partitions where there isn't enough space in the target. One thing I did see however, is that the xfs::copy() procedure seems to have a race condition in the umount after the copy has happened. Occasionally it tries to unmount the destination and fails as it seems that the xfsrestore program is still writing to the disk. It currently umounts the destination first then the source. I've included a patch which reverses this so the source is first unmounted then the destination and with this I couldn't replicate the race condition. Thanks! steveybaby2
Created attachment 201290 [details] [review] Patch to reverse order of umounts after xfs copy
Thank you for the patch to reverse the unumount order. In the patch I noticed that the email address appears to be invalid. For the git records to be complete, a valid email address is required. Would you be able to provide an updated patch with a correct email address? If you are concerned about publishing your name and email address, then I could make the changes myself and commit these under my own name and email address. My preference is to give credit where credit is due.
Created attachment 201315 [details] [review] Patch to reverse order of umounts after xfs copy (revised)
Well spotted - please see newly attached patch.
Thank you Stephen for the updated patch. This has been committed (with some minor changes) and can be viewed at the following link: http://git.gnome.org/browse/gparted/commit/?id=e247357b51ceb92365c4bc02e92a7698c5324d48
The enhancement to address this bug report has been included in GParted 0.11.0 released on Dec. 13, 2011.