Many file systems report differing percentages of unallocated space over
a range of sizes, as well differing figures using their own specific
tools or using statvfs() system call when mounted.
File systems reporting intrinsic unallocated space using their specific
tools are: jfs, lvm2 pv and ntfs. LVM2 PV has the largest amount of
unallocated space with its default Physical Extent size of 4 MiB. For a
100 MiB partition it has 4.0% unallocated space.
File systems reporting intrinsic unallocated space using the statvfs()
system call when mounted are: ext2/3/4, fat16/32, hfs, jfs, nilfs2,
ntfs, reiserfs, and xfs. Xfs has the worst identified unallocated space
of ~4.7% in a 100 MiB partition. Ext2/3 exhibit unusual behaviour by
reporting unallocated space of ~4.6% in a 100 MiB partition falling to a
constant percentage of ~1.8% for sizes of 1 GiB and above.
Update the calculation for used to estimate the maximum size of
intrinsic unallocated space. Limit is now 5% for partitions smaller
than 100 MiB, 2% for partitions larger than 1 GiB and linear scaling of
the percentage between. Will still get false unallocated space warnings
for mounted xfs file systems and lvm2 pvs smaller than 100 MiB.
Also add a short note and worked example calculation of unallocated
space to the HACKING file.
Bug #499202 - gparted does not see the difference if partition size
differs from filesystem size
A number of file systems report intrinsic unallocated space even when
they are created filling the partition. As reported using their own
specific tools, they are: jfs, lvm2 pv and ntfs. Therefore when
resizing a partition estimate its minimum size to be used sectors plus
any unallocated sectors up to the significant amount.
Bug #499202 - gparted does not see the difference if partition size
differs from filesystem size
The btrfs programs only provide approximations of file system sizes
because they display figures using binary prefix multipliers to two
decimal places of precision. E.g. 2.00GB. For partition sizes where
the contained file system size rounds upwards, GParted will fail to read
the file system usage and report a warning because the file system will
appear to be larger than the partition.
For example, create a 2047 MiB partition containing a btrfs file system
and display its size.
# btrfs filesystem show
Label: none uuid: 92535375-5e76-4a70-896a-8d796a577993
Total devices 1 FS bytes used 28.00KB
devid 1 size 2.00GB used 240.62MB path /dev/sda12
The file system size appears to be 2048 MiB, but that is larger than the
partition, hence the issue GParted has. (Actually uses the btrfs devid
size which is the size of the btrfs file system within the partition in
question).
This issue is new with the fix for Bug #499202 because it queries the
file system sizes for the first time. The same issue could
theoretically occur previously, but with the used figure (FS bytes
used). This would have been virtually impossible to trigger because
btrfs file system would have to have been greater than 99% full, but
btrfs has been notorious for early reporting of file system full.
The fix is that if a btrfs file system size appears larger than the
partition size, but the minimum possible size which could have been
rounded to the reported figure is within the partition size use the
smaller partition size instead. Apply the method to the used figure
too, in case the file system is 100% full. Also if the btrfs file
system size appears smaller than the partition size, but the maximum
possible size which could have been rounded to the reported figure is
within the partition size use the larger partition size instead to avoid
reporting, presumably false, unallocated space. Not applied to file
system used figure.
Bug 499202 - gparted does not see the difference if partition size
differs from filesystem size
When pasting a copied partition into free space or move/resizing a
partition set its space utilisation so that any unallocated space within
the partition is displayed correctly before the operation is applied.
NOTE:
If the file system does not support file system resizing the Paste and
Move/Resize dialogs don't allow resizing the partition so the preview
will always be correct, unlike the case in the previous patch:
Set unallocated space when performing simple operations (#499202)
Also remove the deprecated and no longer used Partition::Set_Unused()
and Partition::set_used() methods.
Bug #499202 - gparted does not see the difference if partition size
differs from filesystem size
When pasting a copied partition into an existing partition set its space
utilisation so that any unallocated space is displayed correctly before
the operation is applied. If the destination partition is larger the
file system will be grown to fill the partition.
NOTE:
GParted will attempt to grow the the file system in this situation
regardless of whether the file system supports it or not. These file
systems: exfat, hfs, hfs+, reiser4 and ufs can't be grown and will fail
with "growing is not available for this file system". The preview will
also be wrong in this case for the same reason. Everything will be
depicted correctly after the refresh.
When formatting an existing partition default its space utilisation to
unknown for display before the operation is applied.
Bug 499202 - gparted does not see the difference if partition size
differs from filesystem size
Display the unallocated space within a partition in the main window's
graphical disk representation.
Bug #499202 - gparted does not see the difference if partition size
differs from filesystem size
Update the implementation using libparted to set the file system size
and free space, thus allowing the unallocated space in the partition to
be calculated, for the following unmounted file systems:
hfs, hfs+
(Requires libparted <= 2.4 or libparted >= 3.1, as the needed
functionality did not exist in libparted 3.0).
Bug #499202 - gparted does not see the difference if partition size
differs from filesystem size
Add reporting of the LVM2 Physical Volume size allowing the unallocated
space in the partition to be calculated.
Bug #499202 - gparted does not see the difference if partition size
differs from filesystem size
Update file system specific implementations to set the size and free
space, thus allowing the unallocated space in the partition to be
calculated, for the following unmounted file systems:
btrfs, ext2, ext3, ext4, fat16, fat32, jfs, nilfs2, ntfs, reiserfs,
reiser4, xfs
Bug #499202 - gparted does not see the difference if partition size
differs from filesystem size
Display the unallocated space in the graphical partition representation
and numeric figures in the Partition Information dialog.
Bug #499202 - gparted does not see the difference if partition size
differs from filesystem size
Currently GParted assumes that a file system fills its containing
partition. This is not always true and can occur when resizing is
performed outside of GParted or a resize operation fails. GParted
doesn't display any information about unallocated space to the user
and in most cases it is simply included in used space.
Add partition unallocated space accounting. Make GParted record the
unallocated space for mounted file system and display a warning in the
Partition Information dialog when too much unallocated space is found.
Partition::set_sector_usage( fs_size, fs_unused ), is the new preferred
method of recording file system usage because it allows the unallocated
space in a partition to be calculated. Partition::Set_Unused() and
Partition::set_used() are now deprecated.
NOTES:
1) Set the minimum unallocated space to be 5% before considering it
significant to avoid false reporting. Worst case found was a
mounted xfs file system in a 100MiB partition, which reports as
~4.7% unallocated according to file system size from statvfs().
However, it reports as having no unallocated space using xfs
specific tools.
2) Unallocated space is only a graphical representation for the user.
GParted must still use relevant tools to resize file systems before
shrinking the data and can't assume all unallocated space exists
after the file system at the end of the partition.
Bug #499202 - gparted does not see the difference if partition size
differs from filesystem size
AFAICS, there is no reason to manually copy all partition fields,
or to manually initialize the copy of the new partition object.
So now the partition object is simply copied using assignment.
AFAICS, there is no reason to manually copy all partition fields,
or to manually initialize the copy of the new partition object.
So now the partition object is simply copied using assignment.
Normally the GUI should restrict partitions from overlapping other
partitions. However we have received a report where an overlap has
occurred.
Unfortunately we did not have enough details to recreate the problem.
Based on the report my thoughts are that somehow the problem arose
due to partitions aligned to boundaries other than MiB in combination
with the size of a partition being rounded up in the GUI resizer.
In an effort to prevent this problem in the future I have added a
check for primary or extended partitions overlapping other primary or
extended partitions.
Closes Bug #661744 - libparted "Can't have overlapping partitions."
after successful move+resize?!
Ensure at least 2 sectors for Extended Boot Record (EBR) between end
of logical partition and start of next logical partition.
Ensure at least 34 sectors reserved for backup GUID Partition Table
(GPT) after the end of the last partition.
GParted_Core::set_device_partitions() creates and initialises the
partition objects based on the partitions on the disk using
partition.Reset() and partition.Set(). These methods never set the
alignment attribute.
Copy and pasting into an existing partition calls GParted_Core::
snap_to_alignment() to adjust the start and end of the newly created
in memory partition object. When pasting into unallocated space the
user has selected the required alignment and this is exactly what is
needed. However when pasting into an existing partition the in memory
partition object should always match the actual partition boundaries on
disk. Unfortunately the partition boundaries are adjusted based on
reading the uninitialised alignment attribute.
Initialise the alignment attribute of newly created partition objects to
ALIGN_STRICT. Also, when pasting into an existing partition set the
alignment of that partition object to ALIGN_STRICT so that no boundary
adjustment is performed.
valgrind:
==6845== Conditional jump or move depends on uninitialised value(s)
==6845== at 0x80C779A: GParted::GParted_Core::snap_to_alignment(...) (GParted_Core.cc:566)
==6845== by 0x810C115: GParted::Win_GParted::Add_Operation(...) (Win_GParted.cc:692)
==6845== by 0x8110499: GParted::Win_GParted::activate_paste() (Win_GParted.cc:1649)
...
==6845== Conditional jump or move depends on uninitialised value(s)
==6845== at 0x80C77A8: GParted::GParted_Core::snap_to_alignment(...) (GParted_Core.cc:568)
==6845== by 0x810C115: GParted::Win_GParted::Add_Operation(...) (Win_GParted.cc:692)
==6845== by 0x8110499: GParted::Win_GParted::activate_paste() (Win_GParted.cc:1649)
GParted_Core.cc:
562 bool GParted_Core::snap_to_alignment( const Device & device, Partition & partition, Glib::ustring & error )
563 {
564 bool rc = true ;
565
>> 566 if ( partition .alignment == ALIGN_CYLINDER )
567 rc = snap_to_cylinder( device, partition, error ) ;
>> 568 else if ( partition .alignment == ALIGN_MEBIBYTE )
569 rc = snap_to_mebibyte( device, partition, error ) ;
570
Closes Bug #672654 - Pasting into an existing partition may shrink
GParted's representation of it
When resizing an extended boot record we must ensure that at least 2
sectors is reserved in front of the nearest logical partition for the
Extended Boot Record.
Please note that unless specifically told otherwise, the Linux kernel
considers Extended Boot Records to be two sectors long, in order to
"leave room for LILO".
Closes Bug #664050 - Unable to resize extended partition
Previously used "fsck.reiser4" to perform a file system check with a by
product of outputting the uuid. However this performs a lot of disk I/O
and takes a while to complete. Instead use the much faster and less
resource intensive "debugfs.reiser4" tool to retrieve the uuid.
The parted-3.1 release brings back FAT16/FAT32 and HFS/HFS+ file
system resize capabilities in a new libparted fs resize library.
The following operations are again available when GParted is linked
with parted-3.1:
FAT16 - grow and shrink
FAT32 - grow and shrink
HFS - shrink
HFS+ - shrink
Note that there is a difference in how move actions are handled for
FAT16/FAT32 file systems based on parted version.
When GParted is linked with parted >= 3.0:
FAT16 - move performed internally by GParted
FAT32 - move performed internally by GParted
When GParted is linked with parted < 3.0:
FAT16 - move performed by libparted
FAT32 - move performed by libparted
Thanks goes to Jim Meyering for restoring these file system resizing
capabilities in Parted 3.1 with a new libparted fs resize library.
Closes Bug #668281 - minimal file-system resize API? (FAT and HFS*
only)
Mike Fleetwood