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 1546815 1546181 1584912
TreeView+ depends on / blocked
 
Reported: 2016-03-31 17:04 UTC by smazul
Modified: 2019-04-04 18:01 UTC (History)
10 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


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


Note You need to log in before you can comment on or make changes to this bug.