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