Now that every call to calc_usage_triple() just passes usage figures
returned by get_sectors_*(), remove those parameters, call
get_sectors_*() internally and rename to get_usage_triple().
Stop using fraction_unallocated and fraction_used member variables of
the DrawingAreaVisualDisk class as intermediate storage of partition
usage fractions. Instead get the figures straight from the partition
class and use the new calc_usage_triple() to directly set pixels widths
for the partition usage graphic.
For specific partition usage values the right hand border of the
partition graphic in the Information dialog would be displayed as grey
rather than the color assigned to the partition.
Steps to reproduce fault:
Create 1024 MiB partition
# lvm pvcreate /dev/sda12
# lvm vgcreate GParted-VG1 /dev/sda12
View partition information
Fragment from Dialog_Partition_Info::init_drawingarea():
139 else if ( partition .sector_usage_known() )
140 {
141 used = Utils::round( ( 400 - BORDER *2 ) / ( dlength / partition .get_sectors_used() ) ) ;
142 unused = Utils::round( ( 400 - BORDER *2 ) / ( dlength / partition .get_sectors_unused() ) ) ;
143 unallocated = 400 - BORDER *2 - used - unused ;
144 }
For this issue the above values are both exactly x.5 and both round
upwards, resulting in unallocated being -1.
used = round((400 - 8*2)/(2097152.0/8192)) = round(1.5)
unused = round((400 - 8*2)/(2097152.0/2088960)) = round(382.5)
unallocated = 400 - 8*2 - 2 - 383 = -1
The simple fix would be to use floor() instead of round() in the
calculation of either used or unused. The same fix would also need to
be applied in Display_Info() for the calculation of the percentage
figures. Unfortunately this simple fix can lead to odd figures when the
used or unused is close to zero and floor() or ceil() is effectively
applied rather than round(). For example:
Size: 227.23 GiB
Used: 28.00 KiB ( 1% )
Unused: 180.00 GiB ( 79% )
Unallocated: 47.23 GiB ( 20% )
Used figure of 28 KiB in 227 GiB partition should be rounded to 0% but
wasn't.
Write Partition::calc_usage_triple() which calculates the "best" figures
by rounding the smaller two figures and subtracts them from the desired
total for the largest figure. Apply to the calculation of the partition
usage percentage figures in the Information dialog and the partition
usage graphic in the same dialog and the main window.
Bug #499202 - gparted does not see the difference if partition size
differs from filesystem size
Most file systems report intrinsic unallocated space using the statvfs()
system call when mounted, but not using their own tools. They are:
ext2/3/4, fat16/32, hfs, nilfs2, reiserfs and xfs. Showing either a
little or no unallocated space, depending on whether a file system is
mounted or not, could be confusing to the user.
When all file systems are created filling their partitions the unused
figure reported by statvfs() and their own tools are the same or very
close. Also the used plus unallocated figure from statvfs() agrees with
the used figure from their own tools.
For all file systems don't display intrinsic unallocated space (that
below the threshold of 2 to 5%), instead include it as used space. As
soon as the amount of unallocated space becomes significant display it
everywhere and also trigger the warning.
For display purposes always use the new Partition methods:
get_sectors_used(), get_sectors_unused(), and get_sectors_unallocated().
When calculating new usage figures during Paste and Resize/Move
operations directly access sectors_used, sectors_unused and
sectors_unallocated members.
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
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
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
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)
Also update to use LVM terminology, such that a Physical Volume is
referred to as a member of a Volume Group. Status of an LVM2 PV is now
displayed using one of the following messages:
Not active (Not a member of any volume group)
VGNAME not active
VGNAME not active and exported
VGNAME active
Bug #160787 - lvm support
GParted would crash if there were any embeded spaces in the output from
the command used to query LVM2 PVs. There aren't normally any embeded
spaces, but they can occur in certain degrated situations. For example
if one of the PVs in a VG spanning two PVs is lost the PV is displayed
as "unknown device" rather than its actual device name:
# lvm pvs --nosuffix --units b --separator , -o pv_name,pv_free,vg_name,lv_name,lv_attr
Couldn't find device with uuid DMEi8r-9Vvy-w0Ok-CSSn-oLmY-YrY3-1PBznz.
PV,PFree,VG,LV,Attr
/dev/sda11,2143289344,GParted-VG1,,
unknown device,1619001344,GParted-VG1,lvol0,-wi---
unknown device,1619001344,GParted-VG1,,
This was loaded into the cache as:
["/dev/sda11,2143289344,GParted-VG1,,",
"unknown",
"device,1619001344,GParted-VG1,lvol0,-wi---",
"unknown",
"device,1619001344,GParted-VG1,,"]
The crash would happen when trying to access the VG name or LV flags on
a line without enough comma separated fields.
Improve parsing of the output from "lvm pvs" so that lines are not split
on embeded spaces. Don't crash on lines without without enough comma
separated fields.
Bug #160787 - lvm support
Previously any errors which occurred when running LVM commands used to
load the LVM2_PV_Info cache were simply ignored and the cache wasn't
loaded. This lead to missing information about LVM2 PVs, but the user
had no indication as to why.
Now when any errors occur the command ran and all output is captured.
This is displayed to the user, along with a suitable warning message, in
the Partition Information dialog.
Bug #160787 - lvm support
Create function Utils::kernel_version_at_least() to check that the
current Linux kernel is a particular version or higher.
Update nilfs2 to use this function to determine whether the kernel is
new enough to support file system resizing.
Previously used "dmsetup info" to directly list device-mapper mapping
names in the kernel to identify active Logical Volumes. However GParted
failed to recognise active LVs if the VGNAME contains any hyphens (-).
This is because LVM encodes hyphens as double hyphens in the mapping
name.
To avoid having to duplicate the LVM hyphen encoding in GParted, switch
to using "lvm lvs" to list LVs.
# dmsetup info --columns --noheadings --separator , -o name
GParted_VG1-lvol_00
GParted--VG2-lvol--00
# lvm lvs --noheadings --separator , -o lv_name,vg_name,lv_attr
lvol_00,GParted_VG1,-wi-a-
lvol-00,GParted-VG2,-wi-a-
lvol-01,GParted-VG3,-wi---
.^.
(-) not active, (a) or any other character considered active. Reference
lvs(8).
Bug #160787 - lvm support
As the Mount Point column is being borrowed to display the PV's VGNAME,
also suppress generation of the "Mount on" submenu for LVM2 PVs.
Bug #160787 - lvm support
Previously when GParted was started LVM2_PV_Info cache was loaded twice,
executing LVM2 PV querying commands twice. Firstly when
lvm2_pv::get_filesystem_support() was checking if LVM2 PV support was
available, and secondly when forced by a refresh in
GParted_Core::set_devices().
Implement lazy initialization. Only load the cache when forced by the
above mentioned refresh or having to return a value when the cache is
not yet loaded. Do not initialize the cache when just checking if LVM2
PV support is available.
Bug #160787 - lvm support
Cache results from querying all LVM2 PVs in one go to minimise the
number of times lvm commands are executed. Take inspiration from
caching performed by FS_Info and Proc_Partitions_Info.
Bug #160787 - lvm support
Add minimal support for just reporting the space usage of LVM2 PVs.
Accept libparted / blkid detection of LVM2 PVs first, falling back on
GParted's specific detection code otherwise. Maintain LVM not supported
warning message.
Bug #160787 - lvm support
This is the first step of adding support for just LVM2 Phyiscal Volumes,
a subset of full LVM2 support.
Make it clear that it is only LVM2 PVs being treated like a file system.
Bug #160787 - lvm support
Add the ability to set a new random UUID on file systems that provide
the appropriate tools to perform this action.
Update the help manual to include this new functionality. Also add
reference links to "setting a partition label" and "changing a
partition UUID" in the "copying and pasting a partition" section.
This patch does not include setting the UUID on an NTFS file system.
Bug #667278 - Add support for setting UUID
Bug #608308 - fix documentation - Copying and Pasting a Partition
There is a lot of commonality and code repetition for resizing of file
systems which can only be resized while mounted. Resizing of btrfs, jfs
and xfs all follow the pattern: mkdir, mount, resize, umount and rmdir.
Copying an xfs file system also uses a similar pattern, but for the
source and destination xfs file systems simultaneously.
Add three helper functions to the FileSystem class which implement
common tasks, allowing mounted file system resizing to be implemented
more simply.
Also add a function to the Utils class which checks whether the kernel
supports a file system. It handles the case of non-loaded modules,
which currently leads to reporting the growing of jfs and xfs as
unsupported.
We used to just log libparted exceptions without handling them. This patch
changes the exception handler to display a modal dialog box and return the
chosen action to libparted.
Requires libparted 2.4 or higher, or blkid from utils-linux 2.20 or
higher for nilfs2 file system detection.
Requires nilfs-utils for nilfs2 file system support.
Closes Bug #642842 - nilfs is not detected
When a new operation is added to operations list, check if a merge
is possible depending on the operation type:
OPERATION_RESIZE_MOVE: 2 consecutive "resize" operations on the
same partition
OPERATION_LABEL_PARTITION: 2 "label change" operations (need not be
consecutive) on the same partition
OPERATION_CHECK: 2 "check" operations (need not be
consecutive) on the same partition
OPERATION_FORMAT: 2 consecutive "format" operations on the
same partition
Closes Bug #438573 - Cancel out overlapping actions
Also fix a bug when copying partition using the Partition::Set(...)
method. This method did not initialize "sectors_used" and
"sectors_unused" members.
Some classes contained private attributes which were used only by a single
member function. Such items were moved to the corresponding function implementations
to stress their limited usage scope.
A few unused variables were also deleted.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
The release of (lib)parted 3.0 includes a change to the Application
Programing Interface - API. Most importantly, libparted 3.0 removes
many file system specific function calls, and hence the capabilities
provided by these functions. In order for GParted to compile and link
with libparted 3.0, this libparted functionality is lost.
Specifically, the functionality that is lost when GParted is compiled
and linked with libparted 3.0 is as follows:
- Loss of ability to grow and shrink FAT16 and FAT32 file systems
- Loss of ability to shrink HFS and HFS+ file systems
- Loss of ability to determine used and unused sectors in HFS and
HFS+ file systems
- Loss of ability to erase file system signatures on partition
create and format
It is hoped that other free software projects will include some or all
of the above lost functionality, which can then be added back to
GParted.
This commit includes a change in how FAT16 and FAT32 file systems are
moved. Specifically the move is now performed internally by GParted
when linked with libparted 3.0. The move functionality is provided by
libparted for prior libparted versions (e.g. less than 3.0).
This is the final enhancement in a series of commits that enable
GParted to compile with libparted version 3.0.
Closes Bug #651559 - Doesn't compile against parted 3.0
Usage of the kpartx package to create partition names has been
completely removed. Hence kpartx is no longer even an optionally used
package by gparted.
This change is related to the following bug report:
Ubuntu launchpad bug 719129 - [Natty] Gparted duplicates dmraid
partition devices
https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/719129
The reason for refactoring is to simplify the large GParted_Core
class, to help minimize disk reads, and to group the logic for
processing the file /proc/partitions into a single logical class.
This reason for refactoring is to simplify the large GParted_Core
class, to help minimize disk reads, and to group the logic for
processing the file /proc/partitions into a single logical class.
This adds initial handlers for Btrfs; only .create, .check and
.read_label are done for now, via external btrfs-tools.
Other methods are still only stubs.
Mike Fleetwood