2. Who is the customer behind the request?
Account: name and acct #
name: Patrick Riehecky
acct #: 646274
TAM customer: yes
SRM customer: no
3. What is the nature and description of the request?
Customer would like to be able to modify labels on mounted xfs filesystems, similar to ext4. Currently, customer must use xfs_admin to accomplish this and can only be done while filesystem is unmount.
4. Why does the customer need this? (List the business requirements here)
A) Our backup and data recovery tools are driven by disk labels.
Drives that contain important/user data that can be backed up directly (ie /home) are labeled in a specific pattern.
Drives that contain important/user data, but require some other tool to generate the backups follow a different pattern (ie mysql -> mysqldump)
When reloading a system disks with important data are treated differently and generally not formatted.
This is a feature we've grown to rely on from EXT2/3/4 where this can be done on mounted filesystems.
Occasionally these values change during the lifespan of the system.
For example, myhost.example.com may not start out running a database, but one may be added later in its lifecycle. When this happens I'd like to tag the filesystem as containing user data.
Requiring a system downtime, and possibly booting into rescue mode, to relabel /var is a meaningful burden on our sysadmins and an inconvenience to the users. This is particularly worrisome for remote data centers where out of band management is required for single user mode.
B) Within our RHEV environment disks are occasionally passed from one host to another. This may result in strange labels appearing
/dev/vda1 -> /
/dev/vdb1 -> /
It can be difficult to correct these labels if the filesystems are mounted and in use leaving the system out of our defined expectations.
5. How would the customer like to achieve this? (List the functional requirements here)
The following solutions are interchangeable to my mind. Whichever is most likely to be implemented is my preference:
- new binary xfslabel whose only feature is to set the volume label on an XFS file system (similar to e2label) that can operate on a mounted volume.
- xfs_admin modified to avoid calls to xfs_db when changing system label
6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.
Testing will consist of attempts to modify mounted xfs filesystems and confirm that the label has changed as well as corruption issues
7. Is there already an existing RFE upstream or in Red Hat Bugzilla?
Did not find any solution
8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)?
Ideally, would like the resolution in the next major release
Customer does not require this feature for RHEL 6, but admits it would be advantageous to have it in both releases
9. Is the sales team involved in this request and do they have any additional input?
10. List any affected packages or components.
11. Would the customer be able to assist in testing this functionality if implemented?
This isn't related to xfsdump...
e2label happily writes to a mounted block device; that's pretty dodgy, and something xfs won't do.
To implement this we'd need a kernel interface to change the label on a mounted fs. It would likely also need to handle changing other superblock details like the UUID. So, moving to kernel component, though we'd also need an xfs tool to use the new interface.
That said, every filesystem already has a unique UUID. Would using the existing unique UUID to look up filesystem content details (elsewhere) not suffice? What sort of labeling scheme is actually in use today?
FWIW, back in 2014 Dave didn't seem opposed to such an interface. So that's good at least. :)
From previously asked questions on comment 2
1) Would using the existing unique UUID to look up filesystem content details (elsewhere) not suffice?
Unfortunately the UUIDs are universally unique. Tracking them would create more complexity. Additionally, I'm unable to change the UUID of a mounted XFS volume so that doesn't really address my primary issue.
2) What sort of labeling scheme is actually in use today?
As for labeling scheme:
/ - contains /
/(data) - contains / and has data we should preserve (ie. /home)
/(tool) - contains / and has data that we should preserve, but is best exported via a tool (ie. mysq/postgresql)
Well, in any case, I am looking into adding online labeling ability to xfs. btrfs has it, and we can hoist that interface to the vfs and make it available to more filesystems including xfs.
I had preliminary patches to do this, but something was behaving oddly w.r.t. block device caching (I think) - labels would successfully update, but they weren't always immediately visible. It'll take some more investigation.
Adding this to the approval for 7.4, but it's not as high of a priority.
There's no code yet for this but I had a (buggy) prototype. I'll take another stab at it, acking for now but ultimately depends on upstream acceptance.
Note, xfs_admin is exclusively an off-line / unmounted tool today, so it's unlikely that we'll use xfs_admin as the user interface to the online label feature.
For now, a new command will be added to xfs_io, i.e.
# xfs_io -c "label mynewlabel" /mount/point
Sent to rhkernel-list on 22 May 2018
Patch(es) committed on kernel repository and an interim kernel build is undergoing testing
Patch(es) available on kernel-3.10.0-914.el7
Sure, I think this counts as an enhancement.
# xfs_io -c "label mynewlabel" /mount/point
is correct, using whatever style you'd like to denote that "mynewlabel" is the label for the XFS filesystem mounted at "/mount/point"
I've written a release note based on how I understand this. If there's anything in the doc text that's incorrect or misleading, please let me know.
I think that's pretty much fine. One tweak you might want is that "previously" the label change was made with the xfs_admin tool, not xfs_io.
(So today, xfs_admin is used for unmounted label operations, xfs_io is used for mounted operations - a little odd but that's how it stands today)
You're right, I should have mentioned that there are two tools for this with different use cases.
I've edited the doc text to (hopefully) make that clear.
This feature has been supported by current el7 kernel, xfstests generic/492 to be basic test case test passed on kernel 934.el7 with xfsprogs 4.5.0-18.el7
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.