GNOME Bugzilla – Bug 663884
[PATCH] Use newer btrfs multi-tool control command first
Last modified: 2011-12-13 17:42:50 UTC
Hi, Here's another btrfs related enhancement for consideration. Applies on top of my other 2 recent btrfs patches. Quoting the commit message: Use newer btrfs multi-tool control command first Btrfsctl and btrfs-show were depreciated in October 2011 and have been superseeded by the newer btrfs multi-tool control command. Use btrfs as first choice, falling back to btrfsctl and btrfs-show when not found. Here's what btrfs-show and btrfsctl have started reporting: $ btrfs-show /dev/sda8 ** ** WARNING: this program is considered deprecated ** Please consider to switch to the btrfs utility ** Label: none uuid: 4baaac67-7336-47b8-a7dd-fc8c6c18fd1f Total devices 1 FS bytes used 28.00KB devid 1 size 1.00GB used 138.38MB path /dev/sda8 Btrfs v0.19-102-g2482539 Not sure if you already know the root cause behind needing commit 47e0c00a "Handle additional return codes from btrfsctl resizing" to accept exit status 256 from btrfsct, but I am fairly confident I have worked it out, so I put a warning comment in the code. Had to do the same workaround for btrfs filesystem resize too. The cause is that resizing a btrfs file system to it's current size results in an error from the resize ioctl() from the kernel btrfs code. Gparted trips over this every time when it performs a partition shrink on the second maximise resize, as it always seems to be resizing the file system to the same size. Never happens on a partition grow which only ever does one resize operation. Hope you can confirm my findings? Wondering if gparted could/should be changed to not perform the second FS resize for a partition shrink if it isn't going to actually change the FS's size? Knowing the cause of a bug is half the battle of fixing it. This can be traced with: strace -e trace=ioctl gpartedbin Thanks, Mike
Created attachment 201255 [details] [review] Enhancement patch
Thank you Mike for all of the work you have put in improving btrfs support. It is much appreciated. :-) I plan to test all three of your patches together and if all goes well I will commit all of these for the next release of GParted. (In reply to comment #0) > The cause is that resizing a btrfs file system to it's current size > results in an error from the resize ioctl() from the kernel btrfs code. > Gparted trips over this every time when it performs a partition shrink > on the second maximise resize, as it always seems to be resizing the file > system to the same size. FYI: This situation would also crop up when GParted is applying a "Partition --> Check" operation. This is because GParted not only performs a file system check, but also runs a maximize file system operation. This is done to ensure that the file system uses all of the space in the partition, and has proved useful in practice. Hence the "partition check" in GParted is more than just a file system check. Consequently I am glad you designed the patch to report success in the situation where a btrfs file system is maximized and already uses all of the partition space. > Wondering if gparted could/should be changed to not perform the second FS > resize for a partition shrink if it isn't going to actually change the > FS's size? That is something I have been thinking about for quite a while. 'Just today a good idea came to me on how to implement this improvement. I am currently testing this change to see if there are any ill side-effects.
This enhancement 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=a580abbc30e88cb1895af342d43dcbb98183a9d5 (In reply to comment #0) > Wondering if gparted could/should be changed to not perform the second FS > resize for a partition shrink if it isn't going to actually change the > FS's size? Bug #663980 has been opened to avoid redundant file system maximize actions on copy, move, and resize.
The enhancement to address this bug report has been included in GParted 0.11.0 released on Dec. 13, 2011.