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 1021051 - lvchange -p should change in-kernel permission if it differs from metadata setting
Summary: lvchange -p should change in-kernel permission if it differs from metadata se...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: lvm2
Version: 6.4
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: pre-dev-freeze
: 6.7
Assignee: Alasdair Kergon
QA Contact: cluster-qe@redhat.com
Steven J. Levine
URL:
Whiteboard:
Depends On:
Blocks: 905665 1002699 1173188
TreeView+ depends on / blocked
 
Reported: 2013-10-18 21:27 UTC by Alasdair Kergon
Modified: 2015-07-22 07:37 UTC (History)
15 users (show)

Fixed In Version: lvm2-2.02.117-1.el6
Doc Type: Enhancement
Doc Text:
lvchange -p now corrects in-kernel permissions on a logical volume If a logical volume is read-only and active but its metadata states that it should be writeable (a situation that can arise if the configuration setting activation/read_only_volume_list is changed), you can now use the "lvchange --permission rw" command to bring the active copy in line with the metadata and make it writeable. Executing an "lvchange --refresh" command can do this as well, but this new feature might be more convenient in some circumstances. The opposite is also true: The "lvchange --permission r" command will now refresh an active logical volume that should be read-only. For information on the lvchange command, see the lvchange(8) man page.
Clone Of:
Environment:
Last Closed: 2015-07-22 07:37:02 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:1411 0 normal SHIPPED_LIVE lvm2 bug fix and enhancement update 2015-07-20 18:06:52 UTC

Description Alasdair Kergon 2013-10-18 21:27:33 UTC 
1) If an LV is activated read-only (using read_only_volume_list), and then that setting is cleared, it would be useful if lvchange -prw would make it rw in the kernel as an alternative to lvchange --refresh.

2) If for any other reason an LV happens to be read-only in the kernel, but its metadata says it should be read-write, it would be useful if lvchange -prw would make it rw in the kernel.

Requested for RHEV's use.
Comment 5 Alasdair Kergon 2015-02-26 18:45:39 UTC 
Create LV (writeable as normal) inactive.  Set read_only_volume_list in config to activate it read-only.  Activate it.  lvs shows R:
                                            
  lvol0  vg6  -Ri-a----- 12.00m  

Remove the read_only_volume_list setting.
run lvchange -prw with current code:

  Logical volume "lvol0" is already writable

Run with new code:

  Logical volume "lvol0" is already writable.  Refreshing kernel state.
  Logical volume "lvol0" changed.

Side-effect: The same happens repeatedly if you still have read_only_volume_list set.

https://lists.fedorahosted.org/pipermail/lvm2-commits/2015-February/003577.html
Comment 6 Alasdair Kergon 2015-02-27 13:40:51 UTC 
Same for -pr if kernel is rw but metadata is already ro.

https://lists.fedorahosted.org/pipermail/lvm2-commits/2015-February/003585.html
Comment 8 Corey Marthaler 2015-04-01 16:17:22 UTC 
SCENARIO (raid1) - [kernel_perm_changes_tag_removal]
Verify in-kernel permission changes are possible when the metadata setting is different
Create a raid with tags that match what is present in the read_only_volume_list and then change the in-kernel permissions

# in /etc/lvm/lvm.conf
    read_only_volume_list = [ "@RO" ]

lvcreate  --type raid1 -n kern_perm -L 300M --addtag RO raid_sanity
  /dev/raid_sanity/kern_perm: write failed after 0 of 4096 at 0: Operation not permitted

kern_perm: attr=rRi-a-r---
kern_perm_rimage_0: attr=IRi-aor---
kern_perm_rimage_1: attr=IRi-aor---

Remove the tags from the raid volume, and attempt to change the in kernel RW permissions
lvchange --deltag RO raid_sanity/kern_perm
lvchange -prw raid_sanity/kern_perm
kern_perm: attr=rwi-a-r---
kern_perm_rimage_0: attr=iwi-aor---
kern_perm_rimage_1: attr=iwi-aor---

Add the tags back to the raid volume, and attempt to change the in kernel RW permissions
lvchange --addtag RO raid_sanity/kern_perm
lvchange -pr raid_sanity/kern_perm
kern_perm: attr=rri-a-r---
kern_perm_rimage_0: attr=iRi-aor---
kern_perm_rimage_1: attr=iRi-aor---

Shouldn't the top level raid volume now have the 'R' (Read-only activation of non-read-only volume) again like it did when originally created?

[root@host-111 ~]# lvs -a -o +devices,lv_tags
  LV                   Attr       LSize   Cpy%Sync Devices                                     LV Tags
  kern_perm            rri-a-r--- 300.00m 100.00   kern_perm_rimage_0(0),kern_perm_rimage_1(0) RO
  [kern_perm_rimage_0] iRi-aor--- 300.00m          /dev/sda2(1)
  [kern_perm_rimage_1] iRi-aor--- 300.00m          /dev/sda1(1)
  [kern_perm_rmeta_0]  eRi-aor---   4.00m          /dev/sda2(0)
  [kern_perm_rmeta_1]  eRi-aor---   4.00m          /dev/sda1(0)
Comment 9 Alasdair Kergon 2015-04-01 16:30:23 UTC 
(In reply to Corey Marthaler from comment #8)

> lvchange -prw raid_sanity/kern_perm
> lvchange --addtag RO raid_sanity/kern_perm

> lvchange -pr raid_sanity/kern_perm

This changes both on-disk and in-kernel perms to read-only.

This bugzilla is about making 'lvchange -p' check (and change) the in-kernel permissions even if the on-disk permissions are already in the desired state.
Comment 10 Corey Marthaler 2015-04-01 22:26:37 UTC 
Filed bug 1208269 for the inconsistencies in the attributes mentioned in comment #8.
Comment 11 Corey Marthaler 2015-04-01 22:42:37 UTC 
Feature verified in the latest rpms.

2.6.32-546.el6.x86_64
lvm2-2.02.118-1.el6    BUILT: Tue Mar 24 08:25:21 CDT 2015
lvm2-libs-2.02.118-1.el6    BUILT: Tue Mar 24 08:25:21 CDT 2015
lvm2-cluster-2.02.118-1.el6    BUILT: Tue Mar 24 08:25:21 CDT 2015
udev-147-2.61.el6    BUILT: Mon Mar  2 05:08:11 CST 2015
device-mapper-1.02.95-1.el6    BUILT: Tue Mar 24 08:25:21 CDT 2015
device-mapper-libs-1.02.95-1.el6    BUILT: Tue Mar 24 08:25:21 CDT 2015
device-mapper-event-1.02.95-1.el6    BUILT: Tue Mar 24 08:25:21 CDT 2015
device-mapper-event-libs-1.02.95-1.el6    BUILT: Tue Mar 24 08:25:21 CDT 2015
device-mapper-persistent-data-0.3.2-1.el6    BUILT: Fri Apr  4 08:43:06 CDT 2014
cmirror-2.02.118-1.el6    BUILT: Tue Mar 24 08:25:21 CDT 2015



# RO -> RW
lvcreate  --type raid1 -n kern_perm -L 300M --addtag RO raid_sanity
  /dev/raid_sanity/kern_perm: write failed after 0 of 4096 at 0: Operation not permitted

[root@host-111 ~]# lvs -a -o +devices
  LV                   Attr       LSize   Cpy%Sync Devices
  kern_perm            rRi-a-r--- 300.00m 100.00   kern_perm_rimage_0(0),kern_perm_rimage_1(0)
  [kern_perm_rimage_0] iRi-aor--- 300.00m          /dev/sda2(1)
  [kern_perm_rimage_1] iRi-aor--- 300.00m          /dev/sda1(1)
  [kern_perm_rmeta_0]  eRi-aor---   4.00m          /dev/sda2(0)
  [kern_perm_rmeta_1]  eRi-aor---   4.00m          /dev/sda1(0)

lvchange --deltag RO raid_sanity/kern_perm

[root@host-111 ~]# lvchange -prw raid_sanity/kern_perm
  Logical volume "kern_perm" is already writable.  Refreshing kernel state.
  Logical volume "kern_perm" changed.

[root@host-111 ~]# lvs -a -o +devices
  LV                   Attr       LSize   Cpy%Sync Devices
  kern_perm            rwi-a-r--- 300.00m 100.00   kern_perm_rimage_0(0),kern_perm_rimage_1(0)
  [kern_perm_rimage_0] iwi-aor--- 300.00m          /dev/sda2(1)
  [kern_perm_rimage_1] iwi-aor--- 300.00m          /dev/sda1(1)
  [kern_perm_rmeta_0]  ewi-aor---   4.00m          /dev/sda2(0)
  [kern_perm_rmeta_1]  ewi-aor---   4.00m          /dev/sda1(0)


# RW -> RO
lvcreate  --type raid1 -m 1 -n kern_perm -L 300M raid_sanity

[root@host-111 ~]# lvs -a -o +devices
  LV                   Attr       LSize   Cpy%Sync Devices
  kern_perm            rwi-a-r--- 300.00m 100.00   kern_perm_rimage_0(0),kern_perm_rimage_1(0)
  [kern_perm_rimage_0] iwi-aor--- 300.00m          /dev/sda2(1)
  [kern_perm_rimage_1] iwi-aor--- 300.00m          /dev/sda1(1)
  [kern_perm_rmeta_0]  ewi-aor---   4.00m          /dev/sda2(0)
  [kern_perm_rmeta_1]  ewi-aor---   4.00m          /dev/sda1(0)

lvchange --addtag RO raid_sanity/kern_perm

[root@host-111 ~]# lvchange -pr raid_sanity/kern_perm
  Logical volume "kern_perm" changed.

[root@host-111 ~]# lvs -a -o +devices
  LV                   Attr       LSize   Cpy%Sync Devices
  kern_perm            rri-a-r--- 300.00m 100.00   kern_perm_rimage_0(0),kern_perm_rimage_1(0)
  [kern_perm_rimage_0] iRi-aor--- 300.00m          /dev/sda2(1)
  [kern_perm_rimage_1] iRi-aor--- 300.00m          /dev/sda1(1)
  [kern_perm_rmeta_0]  eRi-aor---   4.00m          /dev/sda2(0)
  [kern_perm_rmeta_1]  eRi-aor---   4.00m          /dev/sda1(0)
Comment 12 Corey Marthaler 2015-04-08 23:19:27 UTC 
Is this supposed to work with clvmd as well? (see bug 1210105)
Comment 13 errata-xmlrpc 2015-07-22 07:37:02 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://rhn.redhat.com/errata/RHBA-2015-1411.html
Note You need to log in before you can comment on or make changes to this bug.