Hide Forgot
Description of problem: This does however work for single machine mirrors. # SINGLE MACHINE [root@taft-03 ~]# lvcreate -m 1 -n mirror -L 100M single Logical volume "mirror" created [root@taft-03 ~]# lvs -a -o +devices LV VG Attr LSize Log Copy% Devices mirror single mwi-a- 100.00M mirror_mlog 100.00 mirror_mimage_0(0),mirror_mimage_1(0) [mirror_mimage_0] single iwi-ao 100.00M /dev/sdb1(0) [mirror_mimage_1] single iwi-ao 100.00M /dev/sdc1(0) [mirror_mlog] single lwi-ao 4.00M /dev/sdh1(0) [root@taft-03 ~]# lvchange -pr single/mirror Logical volume "mirror" changed [root@taft-03 ~]# lvs -a -o +devices LV VG Attr LSize Log Copy% Devices mirror single mri-a- 100.00M mirror_mlog 100.00 mirror_mimage_0(0),mirror_mimage_1(0) [mirror_mimage_0] single iwi-ao 100.00M /dev/sdb1(0) [mirror_mimage_1] single iwi-ao 100.00M /dev/sdc1(0) [mirror_mlog] single lwi-ao 4.00M /dev/sdh1(0) # CLUSTER [root@grant-03 ~]# lvcreate -m 1 -n mirror -L 100M cluster Logical volume "mirror" created [root@grant-03 ~]# lvs -a -o +devices LV VG Attr LSize Log Copy% Devices mirror cluster mwi-a- 100.00M mirror_mlog 68.00 mirror_mimage_0(0),mirror_mimage_1(0) [mirror_mimage_0] cluster Iwi-ao 100.00M /dev/sdb1(0) [mirror_mimage_1] cluster Iwi-ao 100.00M /dev/sdb2(0) [mirror_mlog] cluster lwi-ao 4.00M /dev/sdc3(0) [root@grant-03 ~]# lvchange -pr cluster/mirror Cannot change permissions of mirror "mirror" while active. [root@grant-03 ~]# lvs -a -o +devices LV VG Attr LSize Log Copy% Devices mirror cluster mwi-a- 100.00M mirror_mlog 100.00 mirror_mimage_0(0),mirror_mimage_1(0) [mirror_mimage_0] cluster iwi-ao 100.00M /dev/sdb1(0) [mirror_mimage_1] cluster iwi-ao 100.00M /dev/sdb2(0) [mirror_mlog] cluster lwi-ao 4.00M /dev/sdc3(0) Version-Release number of selected component (if applicable): 2.6.18-265.el5 lvm2-2.02.84-4.el5 BUILT: Thu Jun 2 05:04:32 CDT 2011 lvm2-cluster-2.02.84-3.el5 BUILT: Wed Apr 27 03:42:43 CDT 2011 device-mapper-1.02.63-3.el5 BUILT: Thu May 19 08:09:22 CDT 2011 device-mapper-event-1.02.63-3.el5 BUILT: Thu May 19 08:09:22 CDT 2011 cmirror-1.1.39-10.el5 BUILT: Wed Sep 8 16:32:05 CDT 2010 kmod-cmirror-0.1.22-3.el5 BUILT: Tue Dec 22 13:39:47 CST 2009 How reproducible: Everytime
I'm sorry, I'm backing out of this one... The code that enforces the inability to change permissions is found in lvchange.c: if ((lv->status & MIRRORED) && (vg_is_clustered(lv->vg)) && lv_info(cmd, lv, 0, &info, 0, 0) && info.exists) { log_error("Cannot change permissions of mirror \"%s\" " "while active.", lv->name); return 0; } I'm sure you could simply remove this check and the permissions would be allowed to change. However, I'm not clear what the goal is here and how the system is suppose to behave when there are multiple machines with file systems mounted - perhaps already with RW permissions. Here is how things look in the single machine case: [root@bp-01 ~]# mount /dev/vg/lv /mnt [root@bp-01 ~]# lvchange -pr vg/lv Logical volume "lv" changed [root@bp-01 ~]# touch /mnt/foo [root@bp-01 ~]# ls -l /mnt total 13 -rw-r--r-- 1 root root 0 Nov 22 16:09 foo drwx------ 2 root root 12288 Nov 22 16:09 lost+found [root@bp-01 ~]# umount /mnt [root@bp-01 ~]# !mount mount /dev/vg/lv /mnt mount: block device /dev/vg/lv is write-protected, mounting read-only So, in the single machine case, we are allowed to change the permissions while the device is open, but the file system can still proceed to use the block device using the permissions it was originally opened with. It is only forced into read-only mode if a mount is attempted after the permission change. It seems to me that it is the right thing to do to force users to deactivate the logical volume in order to change the permissions. This forces them to unmount their file systems. After all, what is the point in changing the permissions on their LV if they are allowed to keep running in the old mode? Unless someone weighs in on this to convince me otherwise, I am closing this bug WONTFIX. (Additionally, I would think it proper to open a new bug to address the exposed issue on single machine illustrated above, but that may actually be expected behavior...)