RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1322930 - [RFE] Allow xfs to modify labels on mounted filesystem
Summary: [RFE] Allow xfs to modify labels on mounted filesystem
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: kernel
Version: 7.2
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Eric Sandeen
QA Contact: Zorro Lang
Marek Suchánek
URL:
Whiteboard:
Depends On:
Blocks: 1298243 1477664 1546181 1546815 1584912
TreeView+ depends on / blocked
 
Reported: 2016-03-31 17:04 UTC by smazul
Modified: 2021-12-10 14:37 UTC (History)
11 users (show)

Fixed In Version: kernel-3.10.0-914.el7
Doc Type: Release Note
Doc Text:
XFS now supports modifying labels on mounted file systems You can now modify the label attribute of mounted XFS file systems using the *xfs_io* utilit # xfs_io -c "label -s new-label" /mount-point Previously, it was only possible to modify labels on unmounted file systems using the *xfs_admin* utility, which is still supported.
Clone Of:
: 1584912 (view as bug list)
Environment:
Last Closed: 2018-10-30 08:10:33 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description smazul 2016-03-31 17:04:02 UTC 
2. Who is the customer behind the request?  
Account: name and acct #
name: Patrick Riehecky
acct #:   646274

TAM customer: yes  
SRM customer: no 
Strategic: yes  
  
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?  
No  

10. List any affected packages or components.  
xfs_admin
xfs_db  

11. Would the customer be able to assist in testing this functionality if implemented?
Yes
Comment 2 Eric Sandeen 2016-03-31 18:58:43 UTC 
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?
Comment 3 Eric Sandeen 2016-03-31 19:01:03 UTC 
FWIW, back in 2014 Dave didn't seem opposed to such an interface.  So that's good at least.  :)
Comment 4 smazul 2016-04-04 18:29:04 UTC 
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)
Comment 5 Eric Sandeen 2016-04-04 18:37:29 UTC 
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.
Comment 10 Eric Sandeen 2016-11-29 15:47:48 UTC 
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.
Comment 11 Mark Thacker 2016-11-30 21:25:58 UTC 
Adding this to the approval for 7.4, but it's not as high of a priority.
Comment 18 Eric Sandeen 2018-04-03 02:18:52 UTC 
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.
Comment 21 Eric Sandeen 2018-05-22 16:34:00 UTC 
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

Thanks,
-Eric
Comment 22 Eric Sandeen 2018-05-22 19:09:56 UTC 
Sent to rhkernel-list on 22 May 2018
Comment 23 Bruno Meneguele 2018-06-22 23:17:57 UTC 
Patch(es) committed on kernel repository and an interim kernel build is undergoing testing
Comment 25 Bruno Meneguele 2018-06-22 23:42:28 UTC 
Patch(es) available on kernel-3.10.0-914.el7
Comment 28 Eric Sandeen 2018-08-07 17:38:47 UTC 
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"

Thanks,
-Eric
Comment 29 Marek Suchánek 2018-08-09 16:26:49 UTC 
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.

Thanks!
Comment 30 Eric Sandeen 2018-08-09 16:31:11 UTC 
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)
Comment 31 Marek Suchánek 2018-08-09 17:47:22 UTC 
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.
Comment 32 Zorro Lang 2018-08-21 07:47:15 UTC 
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
Comment 34 errata-xmlrpc 2018-10-30 08:10:33 UTC 
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.

https://access.redhat.com/errata/RHSA-2018:3083
Comment 37 Sean M. Brannon 2020-03-24 08:09:48 UTC 
(In reply to Eric Sandeen from comment #28)
> 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"
> 
> Thanks,
> -Eric

There is a mistake in this example. It should be:


xfs_io -c "label -s mynewlabel" /mount/point

label alone displays label
label -c clears a label
label -s sets a new label
Note You need to log in before you can comment on or make changes to this bug.