Did a search for LVM at the CentOS bugzilla. Nothing seems to match this
scenario. If no one contradicts me, I'll also post this in the bug
reporting system. Wanted to a) get confirmation, if possible before
bugging it and b) warn other souls that may be adventurous too!
Summary: failings in LVM and kernel(?) seem to make a "freeze" possible.
1) Lvchange --permission=r seems to not take effect until re-boot even
though lvdisplay says it has taken effect;
2) Prior to reboot, mount will mount a read-only LV and give no
warning that it is read-only and will mount it r/w. The opposite
also occurs: if the LV was ro and it is changed to r/w, mount still
acts as if read-only is in effect.
3) If these steps are done, *ALL* commands work as if everything is
normal *except* "ro" seems to have no effect:
- lvchange --permission=r # Seems OK
- lvdisplay # Seems OK, says "r"
- mount <normal mount args> # Only "t -ext2" extra, no "read
# only" warning from mount command
- >/mnt/the_mount_point/test # Seems OK, ls shows it
- rm /mnt/the_mount_point/test # Seems OK, ls doesn't show it
What would happen if I did not umount it here? I guess it would run for
at least some time without problem. Then, if LVM truly has it ro, when
buffer flush time came there should be some undesirable results.
At this point, I issued a umount for the volume and the system froze
with blinking keyboard LED.
Subsequent re-boot and investigation added the knowledge that the change
in lv status was delayed until reboot.
Can/will anyone confirm/deny this for me? Thx.
Node: Athalon, CentOS-4.3. fully updated, all normal components from
base (wine and a few odds and ends from rpmforge).
============ Gory Details Below ======================================
Progressing on LVM education and simplified b/u procedure using it.
Covered my butt by setting the lv to read only. Got the hare-brained
idea to see what would happen if... >>:-(
# Protect fools from themselves.
# umount /dev/VolGroupAA/lvol1
# lvchange --permission r VolGroupAA/lvol1
Logical volume "lvol1" changed
# lvdisplay VolGroupAA/lvol1 # Edited below to items of interest
--- Logical volume ---
LV Name /dev/VolGroupAA/lvol1
VG Name VolGroupAA
LV Write Access read only
LV Status available
# open 0
LV Size 9.31 GB
Current LE 298
Block device 253:3
# Notice: no read-only this mount & no warning from mount command
# mount -t ext2 /dev/VolGroupAA/lvol1 /mnt/VolGroupAA_lvol1
# > /mnt/VolGroupAA_lvol1/test # ls show file created
# rm /mnt/VolGroupAA_lvol1/test # ls shows file gone
# umount /dev/VolGroupAA/lvol1 # Instant petrification!
Purgatory entered: flashing keyboard LED and the usual three-fingered
salute and destructive pounding on attached peripherals had the expected
results! NADA!
Googled here (it wrapped, sorry)
http://groups.google.com/groups/search?hl=en&lr=&q=read-only+mount
+write+LVM2+kernel+2.6+2006+lock+OR+crash&qt_s=Search
Didn't see anything that looks like it. Saw a drbd related elsewhere
that might come close... but NOPE!
Anyway, since it seems (according to the HOWTO) that only mailing list
activities report and address bugs (didn't see a bugzilla: did I look
too casually?) I would like to confirm this is not peculiar to my node.
I prefer not to subscribe to another list just to belatedly discover
nothing of value after searching their archives too!
If anyone else has a test machine and time, I will take the trouble to
report this if it is confirmed.
Subsequent reboot and test from the console gave this surprise.
# lvchange --permission rw VolGroupAA/lvol1
Logical volume "lvol1" changed
# mount -t ext2 /dev/VolGroupAA/lvol1 /mnt/VolGroupAA_lvol1
mount: block device /dev/VolGroupAA/lvol1 is write-protected, mounting
read-only
#
There I realized that the status change was not propagated to the system
until a re-boot. Later I tried adding a "lvchange --refresh" although
the docs didn't seem promising. It had no effect.
Confiming again, re-booted and did this. Note the read/write access.
# lvdisplay /dev/VolGroupAA/lvol1
--- Logical volume ---
LV Name /dev/VolGroupAA/lvol1
VG Name VolGroupAA
LV UUID jDoW7T-e7IS-Z5Zd-F1lG-3E6S-DvDl-bxYq7d
LV Write Access read/write
LV Status available
# open 0
LV Size 9.31 GB
Current LE 298
Segments 1
Allocation inherit
Read ahead sectors 0
Block device 253:3
# lvchange --permission r VolGroupAA/lvol1
Logical volume "lvol1" changed
# lvdisplay /dev/VolGroupAA/lvol1
--- Logical volume ---
LV Name /dev/VolGroupAA/lvol1
VG Name VolGroupAA
LV UUID jDoW7T-e7IS-Z5Zd-F1lG-3E6S-DvDl-bxYq7d
LV Write Access read only
LV Status available
# open 0
LV Size 9.31 GB
Current LE 298
Segments 1
Allocation inherit
Read ahead sectors 0
Block device 253:3
# mount -t ext2 /dev/VolGroupAA/lvol1 /mnt/VolGroupAA_lvol1
# Note: no warning about read-only issued.
# mount
<snip uninteresting stuff>
/dev/mapper/VolGroupAA-lvol1 on /mnt/VolGroupAA_lvol1 type ext2 (rw)
# >/mnt/VolGroupAA_lvol1/test
# ls -ltr /mnt/VolGroupAA_lvol1
total 6486852
-rw-r--r-- 1 <snip> 290155835 Jul 25 12:25 ImportedHardDisks.tar.bz2
drwx------ 2 <snip> 16384 Jul 25 16:53 lost+found
-rw-r--r-- 1 <snip> 6345862846 Jul 25 20:49 TestDisk_Test.tar.bz2
-rw-r--r-- 1 root root 0 Jul 27 11:56 test
# umount here will lock machine. I'll finish mail first.
TIA
--
Bill
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.centos.org/pipermail/centos/attachments/20060727/b3f5d044/attachment-0004.sig>