CentOS - Jul 2006 - Bug: lvchange delayed until re-boot. System lock up experienced.

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-0001.sig>

On Thu, 2006-07-27 at 12:50 -0400, William L. Maltby
wrote:
> <snip>
In a post here

  http://lists.centos.org/pipermail/centos/2006-July/067553.html

I said
> Can/will anyone confirm/deny this for me? Thx.
And got no response. So I don't know if anyone has an interest.

Regardless, it seems to be fixed with the 4.4 updates, if I tested
properly.

--
Bill