Create common cache search and index functions get_attr_by_name() and
get_attr_by_row() as the existing ones, get_pv_attr_by_*() and
get_vg_attr_by_*(), only differ from each other by the string vector
they use.
If an LVM2 Volume Group has two or more missing Physical Volumes, the VG
is displayed as only having one "unknown device" because
get_vg_members() only adds unique names to the list of members.
# lvm pvcreate /dev/sda11 /dev/sda12 /dev/sda13
# lvm vgcreate Test-VG1 /dev/sda11 /dev/sda12 /dev/sda13
# wipefs -a /dev/sda12
# wipefs -a /dev/sda13
View partition information in GParted
The simplest fix would be to include the PV's UUID in the cache of LVM2
information and add PV names based on unique UUIDs being a member of the
relevant VG. Unfortunately "lvm pvs" seems to have a bug when
displaying Logical Volume attributes, and there are two or more missing
PVs, which causes one of the PVs to be displayed multiple times, rather
than displaying each PV once.
Without LV attributes, every PV is listed:
# lvm pvs --nosuffix --separator , --units b -o pv_name,pv_uuid,vg_name,vg_attr 2> /dev/null
PV,PV UUID,VG,Attr
/dev/sda11,pJ3R51-AOPP-rKlr-CKCT-nfPS-G5FP-B5Vyjm,Test-VG1,wz-pn-
unknown device,Y72oSm-uBcE-ktZL-OIFA-Q129-Uv1B-x5IsrA,Test-VG1,wz-pn-
unknown device,1ESORF-7wlR-0tnO-fy2z-nOL1-MrnJ-2O5yjK,Test-VG1,wz-pn-
With LV attributes, one missing PV is repeated:
# lvm pvs --nosuffix --separator , --units b -o pv_name,pv_uuid,vg_name,vg_attr,lv_name,lv_attr 2> /dev/null
PV,PV UUID,VG,Attr,LV,Attr
/dev/sda11,pJ3R51-AOPP-rKlr-CKCT-nfPS-G5FP-B5Vyjm,Test-VG1,wz-pn-,,
unknown device,Y72oSm-uBcE-ktZL-OIFA-Q129-Uv1B-x5IsrA,Test-VG1,wz-pn-,,
unknown device,Y72oSm-uBcE-ktZL-OIFA-Q129-Uv1B-x5IsrA,Test-VG1,wz-pn-,,
Also "lvm vgs" and "lvm lvs" don't display anything when including both
VG and LV attributes.
Instead query the LVM2 information in two separate commands, one
querying PV attributes and one querying VG and LV attributes, saving the
results in lvm_pv_cache and lvm_vg_cache respectively.
Bug #670171 - Add LVM PV read-write support
Active LVM2 PVs have the partition class busy member set in
GParted_Core::set_device_partitions() just as mounted file systems do.
This is a basic requirement for GParted so that it only manipulates
partitions and contained file systems when they are not in use.
Add const qualifier to get_pv_attr_by_path() and get_pv_attr_by_row() as
they only access member variables read-only.
Make lvm2_pv_attr_to_num() a static member function as it doesn't access
any member variables.
For LVM2 Physical Volumes the Volume Group name was looked up multiple
times, sometimes from the secondary location of the mount point and at
other times from the primary location in the LVM2_PV_Info class. Just
lookup the VG name once from the primary location.
Rename functions and a variable to use a generic term for the menu item
which changes the busy state of partitions now that it also activates
and deactivates LVM2 Physical Volumes as well as mounting and unmounting
file systems and enables and disables swap partitions.
The new delete non-empty LVM2 Physical Volume warning dialog uses
Gtk::MessageDialog::get_message_area() in the display of Volume Group
members. This function was new in gtkmm 2.22, released September 2010,
which is not available in a number of current distributions including:
Unbuntu 10.04 LTS, RHEL 6.3, SLES 11-SP2, Debian 6.0.
Implement fallback method to display the VG name and member PVs in the
warning dialog for when get_message_area() is not available.
Bug #670171 - Add LVM PV read-write support
When attempting to delete a non-empty LVM2 Physical Volume (one which is
still a member of a Volume Group) display a warning dialog which
includes the VG name and a list of the PV members to allow the user to
make an informed choice whether to go ahead and perform the deletion or
cancel to the operation. This dialog is displayed when a partition
containing a PV is being deleted or being overwritten by being
reformatted or pasted into.
Bug #670171 - Add LVM PV read-write support
Implement remove() method so that the LVM2 metadata is updated to
reflect the removal of the LVM2 Physical Volume as well as removing the
signature from the PV before the partition is deleted or overwritten.
lvm pvremove /dev/DEVICE
Also specifically force the removal of the PV when it is a member of a
Volume Group so that it will succeed.
RATIONAL:
If the PV was not removed before the partition was deleted or
overwritten, LVM2 would be left in a broken state with metadata
describing missing PVs for any partially deleted VGs. This leaves the
user needing to perform recovery of a lost PV, which required in depth
understanding of LVM2 and is beyond the scope of what GParted can
currently provide.
The alternative is to use the pvremove command to instruct LVM2 to
remove the PV and update LVM2 metadata to reflect the removal of the PV.
For PVs which are a member of a VG this includes forcing the removal.
This has the impact of making recovery from accidental deletion of a
partition containing a PV irrecoverable. GParted is not able to recover
this situation anyway because Device -> Attempt Data Rescue, using the
gpart command, is not able to detect the signature of an LVM2 PV.
Choose to remove the PV, forcibly if required, rather than potentially
leave LVM2 with missing PVs.
Bug #670171 - Add LVM PV read-write support
This commit only adds a remove() method to every file system and an
optional call to it in the relevant operations. All remove() methods
are no operations and not enabled.
The remove() method provides explicit controlled removal of a file
system before the partition is deleted or overwritten by being formatted
or pasted into. When implemented, it appears as an extra step in the
relevant operation. The file system specific remove() method is
explicitly allowed to fail and stop the operations currently being
applied.
This is different to the existing erase_filesystem_signatures() which
wipes any previous file system signatures immediately before a new file
system is written to ensure there is no possibility of the partition
containing two or more different file system signatures. It never fails
or reports anything to the user.
NOTE:
Most file systems should NOT implement a remove() method as it will
prevent recovery from accidental partition deletion.
Bug #670171 - Add LVM PV read-write support
Copy operation for LVM2 Physical Volumes is deliberately not implemented
because it doesn't fit with how LVM2 works and is not safe in the
general case without an understanding of its internals. See comment in
lvm2_pv::copy() for more details.
Bug #670171 - Add LVM PV read-write support
In the Partition menu enable activation / deactivation of the LVM2
Volume Group of which the Physical Volume is a member.
Bug #670171 - Add LVM PV read-write support
Add creation of Physical Volumes specifying LVM2 metatdata format:
lvm pvcreate -M 2 /dev/DEVICE
Also set the partition type to identify its contents as LVM. Note that
libparted treats every partition type as a file system except LVM which
it treats as a flag, hence GParted displaying "lvm" in the Manage Flags
dialog. Never the less libparted set the partition types correctly.
For MBR partitioning the type is 8e "Linux LVM" and for GPT partitioning
the type is E6D6D379-F507-44C2-A23C-238F2A3DF928. Setting the partition
type as LVM is not strictly required as LVM2 scans the contents of all
partitions looking for PVs, but it is best practice.
Bug #670171 - Add LVM PV read-write support
Steps to reproduce:
1) Open any of these dialogs: Create New Partition, Resize/Move or
Paste;
2) Update any of the following numeric entry fields to a different value
using the keyboard: Free space preceding, New size or Free space
following;
3) Press [Esc] key;
Gparted crashes.
What is happening is that the [Esc] key is leading to the dialog being
closed and calling the ~Dialog_Base_Partition() destructor. However
after this the GTK widget is calling the on_spinbutton_value_change()
registered callbacks for the change to the other two values, on the now
just deleted object.
Fix by disconnecting the change notification callbacks in the
destructor.
Closes bug #682658 - GParted crash by pressing Esc in dialogs with
number entry
The mount of lost file systems that were larger than a 32 bit integer
could hold (~2 GiB), or started after the first ~2 GiB of disk, would
fail.
Closes Bug #680740 - Gparted fails when mounting the read-only view of
lost filesystems
The member functions btrfs_size_to_num(), btrfs_size_max_delta() and
btrfs_size_to_gdouble() don't access any member variables. Therefore
they don't need the const qualifier allowing them to be called when the
btrfs object is const for read-only access to member variables, but
instead need to be static member functions with no access to member
variables.
When resizing an extended partition, a problem can occur with MiB
alignment wherein the requested end sector could be less than the end
sector of the last logical partition. This would be an invalid
geometry because all the logical partitions must be wholly contained
within the extended partition.
Check for this situation and if found then set requested end for
the extended partition to the end of the last logical partition.
Closes Bug #678831 - Partition End Overlap when Resizing Extended
Partition
Restore intended logic accidentally changed by my recent commit:
Simplify calc_usage_triple() interface and rename
6c96ab34b3
Set each display integer to zero if the associated usage value is
negative, rather than setting 100% unused for unknown usage. Graphical
display of partition usage for unknown and unsupported file system types
is not affected and continues to be all white because of the logic in
the callers.
Local variables used, unused and unallocated were hiding class member
variables of the same name. Remove first two local variables as they
were only accessed once and rename third.
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().
Mike Fleetwood