Traced debugreiserfs on a 10GiB reiserfs file system which was 100% full
full with nearly 900,000 files. It read exactly three 4KiB blocks from
different offsets and the program never took more than 0.1 seconds.
A user had a 190 MiB partition containing an old ext2 file system. When
unmounted it was reported as filling the partition, but when mounted it
was reported as having 6% unallocated space. The file system's inode
tables were approximately twice the size of those created by default
with the current mkfs.ext2 defaults.
To create an equivalent file system in a 190 MiB partition:
mkfs.ext2 -N 97344 /dev/sda15
It turns out that for ext2, ext3 and ext4 file systems what was
described as intrinsic unallocated space during the development of
Bug #499202 is actually file system overhead. When mounted the ext2/3/4
kernel code reports the size of the file system after subtracting the
overhead. Overhead is made up of superblock backups, group descriptors,
allocation bitmaps and largest of all inode tables. E2fsprogs tools
don't subtract this overhead when reporting the file system size.
References:
* The Second Extended File System, Internal Layout, by Dave Poirier
http://www.nongnu.org/ext2-doc/ext2.html
* Linux ext2_statfs() function
http://lxr.linux.no/#linux+v3.5.3/fs/ext2/super.c#L1311
Call the file system specific method for reading the usage of ext2, ext3
and ext4 file systems while mounted. Make it read the file system size
from the on disk superblock to avoid subtraction of overhead and use the
statvfs() system call to return an up to date free space figure.
Bug #683255 - ext2: statvfs differs from dumpe2fs (x MB unallocated
space within the partition)
Each file system class can now choose how the size and free space of the
file system is determined when it is mounted.
.fs.online_read = FS::NONE (default)
Do nothing. Don't get the file system size and free space.
.fs.online_read = FS::GPARTED
Use internal GParted method which calls statvfs() system call on
the mounted file system.
.fs.online_read = FS::EXTERNAL
Call the file system's member function set_used_sectors(). This
is the same function as called when the file system is not
mounted. It can determine if the file system is mounted or not
by testing partition.busy and acting accordingly.
This means that determining the size and free space of active LVM2
Physical Volumes is no longer a special case. Instead the lvm2_pv class
just elects to have its set_used_sectors() method called for both the
active and deactive cases.
Bug #683255 - ext2: statvfs differs from dumpe2fs (x MB unallocated
space within the partition)
Vol_id command was deprecated in May 2009 and superseded by the blkid
command. Replace the generic vol_id command with the file system
specific debugfs.reiser4 command to read the file system label.
Debugfs.reiser4 will exist as it's already required to read the file
system usage and UUID.
Use the new RFC 4122 none Nil UUID regular expression to validate the
UUID read in all the Linux native file system specific read_uuid()
methods. No longer need to explicitly exclude "<none>" or all zeros Nil
UUID as the regular expression does this.
Not necessary but use the simpler file system tune command rather than
the file system debug command where possible. Also saves creating an
echo process.
For a mounted reiserfs file system with a Nil UUID (all zeros) GParted
will display a partition specific warning. This comes from the reiserfs
specific read_uuid() method. Error demonstration:
# blkid /dev/sda15
/dev/sda15: LABEL="test-reiserfs-2" TYPE="reiserfs"
# mount | grep sda15
/dev/sda15 on /mnt/2 type reiserfs (rw,relatime)
# reiserfstune /dev/sda15
reiserfstune: Reiserfstune is not allowed to be run on mounted filesystem.
Switch to using debugreiserfs to read the UUID as it can be used on a
mounted file system.
# debugreiserfs /dev/sda15 2> /dev/null | grep UUI
UUID: 00000000-0000-0000-0000-000000000000
Bug #684115 - Reiserfs UUID reading issues on Fedora and CentOS
On Fedora up to and including Fedora 16 and Red Hat and CentOS up to the
current 6.3 release the UUID of an unmounted reiserfs file system is
displayed as "<no" and a GTK markup warning is written to the terminal.
This was because the reiserfs-utils package isn't linked with libuuid
support so reiserfs file systems were created with a Nil UUID (all
zeros). To read the UUID GParted first tries to retrieve the UUID from
the blkid command output via the FS_Info cache. Secondly it tries the
reiserfs file system specific read_uuid() method which uses the first
space separated word following the text "UUID:", hence it gets "<no".
# debugreiserfs /dev/sda15 2> /dev/null | grep UUID
UUID: <no libuuid installed>
In September 2012 Red Hat bug 660285 "reiserfstune compiled without UUID
support" was fixed for Fedora 16 and later releases. On Fedora with
this fix applied GParted will display the Nil UUID (all zeros) for a
previously created reiserfs file system rather than suppressing it.
Only accept valid, none Nil UUIDs in the reiserfs file system specific
read_uuid() method.
Bug #684115 - Reiserfs UUID reading issues on Fedora and CentOS
Rescanning for supported actions in the File System Support dialog was
not detecting the removal and restoration of the lvm command. GParted
was only updating supported actions after refreshing all devices.
Checking for the lvm command was tied to the refresh of the LVM2_PV_Info
cache, hence the behaviour. Fix by always checking for the lvm command
when requested.
Also remove extra new line from end of an error message in
load_lvm2_pv_info_cache().
As LVM2 Physical Volumes can't be resized when they are members of
exported Volume Groups add a warning message to explain this fact.
Display the message as a partition specific warning and as additional
text when growing the file system to fill the partition is skipped for
the check operation and when pasting into an existing larger partition.
Bug #670171 - Add LVM PV read-write support
When an inactive LVM2 Volume Group is exported it makes it unknown to
the local system, ready for moving the member Physical Volumes to
another system, where the VG can be imported and used. In this state a
PV can't be resized.
# lvm pvresize /dev/sda10
Volume group Test-VG1 is exported
Unable to read volume group "Test-VG1".
0 physical volume(s) resized / 1 physical volume(s) not resized
# echo $?
5
Fix this by preventing resizing of such a PV. This has been coded in a
generic way using new function filesystem_resize_disallowed() to
determine whether a file system is allowed to be resized or not. For
a file system which can be resized, but is currently not allowed to be
resized, the behaviour is as follows:
1) Pasting into unallocated space is limited to creating a new
partition which is the same size as the copied partition.
2) Resizing the partition is disallowed, only moving the partition is
allowed.
3) Pasting into an existing partition will only copy the file system.
If the destination partition is larger a warning will report that
growing the file system is not currently allowed.
4) Checking a partition will also report a warning that growing the
file system is not currently allowed.
This is exactly the same behaviour as for a file system which does not
implement resizing, except for a different warning message.
Bug #670171 - Add LVM PV read-write support
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
Curtis Gedak