Bug 1324463

Note - the 'Write Access'  will still be reported as  read/write
since it is STILL writable  - as that's unrelated.

But some new field  like  Health  or something like that will expose problem with healthiness issue on the thin volume/pool....

(In reply to Roman Bednář from comment #0)
> The recommended lvm tools (lvs, pvs, vgs...)
> display the change in state correctly, however if user enters "older",
> although still available, commands like vgdisplay and lvdisplay. The state
> reported there is still "read/write" even though this might be no longer
> true.

> # lvdisplay vg/test

> >>VG Access             read/write

> # lvs -a

>   LV              VG         Attr       LSize   Pool Origin Data%  Meta% 
> Move Log Cpy%Sync Convert
>   POOL            vg         twi-cotzM-  20.00g             0.00   98.83    


I'm confused - you say lvs and lvdisplay show different information, but they both show the same there - w = read/write.

I admit my previous description was not entirely clear. So I went through that again more carefully:

The problem I see is when we run out of metadata space, 'lvs' tells us that there is something wrong with thin pool using "M(metadata read only)" flag. I understand from what you said that 'read only' lv state is something completely else than this "M(metadata read only)" state and that is completely fine. 
However, the message in logs tells users otherwise (switching pool to read-only mode) which is sort of contradiction then, since it's not "read-only" in fact, but rather "metadata read-only". 
'lvs -o name,health_status vg' confirms this statement.

As far as I know it is intended to give I/O errors for all thin LVs in this or similar state of pool failure. Although I believe telling users their thinpool is writable while it's basically not isn't a good approach.

In conclusion: I would suggest at least having the log message changed to giver users more accurate information.


===============================================================
# tail /var/log/messages 
Apr  7 03:28:21 host-015 lvm[31592]: WARNING: Thin pool vg-POOL-tpool metadata is now 91.41% full.
Apr  7 03:29:58 host-015 kernel: device-mapper: space map metadata: unable to allocate new metadata block
Apr  7 03:29:58 host-015 kernel: device-mapper: thin: 253:4: metadata operation 'dm_pool_commit_metadata' failed: error = -28
Apr  7 03:29:58 host-015 kernel: device-mapper: thin: 253:4: aborting current metadata transaction
>>>Apr  7 03:29:58 host-015 kernel: device-mapper: thin: 253:4: switching pool to read-only mode
>>>Apr  7 03:29:58 host-015 kernel: device-mapper: thin: 253:4: unable to service pool target messages in READ_ONLY or FAIL mode


# lvs -a | grep -v lvol
  ...
  WARNING: /dev/vg/lvol250: Thin's thin-pool needs inspection.
  LV              VG         Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
 >POOL            vg         twi-cotzM-  10.00g             0.00   98.83                           
  [POOL_tdata]    vg         Twi-ao----  10.00g                                                    
  [POOL_tmeta]    vg         ewi-ao----   2.00m                                                    
  ...



# lvdisplay vg/POOL
WARNING: /dev/vg/lvol250: Thin's thin-pool needs inspection.
  --- Logical volume ---
  LV Name                POOL
  VG Name                vg
  LV UUID                U5XfHh-arkW-wMlC-OsWr-nkvq-BheJ-n9zscn
> LV Write Access        read/write
  LV Creation host, time host-015.virt.lab.msp.redhat.com, 2016-04-07 03:15:46 -0500
  LV Pool metadata       POOL_tmeta
  LV Pool data           POOL_tdata
  LV Status              available
  # open                 486
  LV Size                10.00 GiB
  Allocated pool data    0.00%
  Allocated metadata     98.83%
  Current LE             5120
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:4
===============================================================

Trying to use the POOL we can see it's not very writable/usable:

# lvremove -y /dev/mapper/vg-lvol100
  WARNING: /dev/vg/lvol250: Thin's thin-pool needs inspection.
  Error locking on node host-015: Failed to process thin pool message "delete 486".
  Failed to suspend vg/POOL with queued messages.
  Failed to update pool vg/POOL.

# tail -n 1 /var/log/messages
Apr  7 04:01:16 host-015 kernel: device-mapper: thin: 253:4: unable to service pool target messages in READ_ONLY or FAIL mode

OR:

# mkfs.ext4 /dev/mapper/vg-lvol1
...
Writing superblocks and filesystem accounting information: done
...

# mount -t ext4 /dev/mapper/vg-lvol1 /mnt/thin
mount: wrong fs type, bad option, bad superblock on /dev/mapper/vg-lvol1,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

# tail /var/log/messages
Apr  7 04:03:16 host-015 kernel: lost page write due to I/O error on dm-6
Apr  7 04:03:16 host-015 kernel: Buffer I/O error on device dm-6, logical block 400
Apr  7 04:03:16 host-015 kernel: lost page write due to I/O error on dm-6
Apr  7 04:03:16 host-015 kernel: Buffer I/O error on device dm-6, logical block 480
Apr  7 04:03:16 host-015 kernel: lost page write due to I/O error on dm-6
Apr  7 04:03:16 host-015 kernel: Buffer I/O error on device dm-6, logical block 560
Apr  7 04:03:16 host-015 kernel: lost page write due to I/O error on dm-6
Apr  7 04:03:16 host-015 kernel: Buffer I/O error on device dm-6, logical block 640
Apr  7 04:03:16 host-015 kernel: lost page write due to I/O error on dm-6
Apr  7 04:03:22 host-015 kernel: EXT4-fs (dm-6): VFS: Can't find ext4 filesystem

You are mixing multiple things together:

LV Write Access   

- it shows the mode used when activating devices (as it is physically store in metadata and is supposed to be change by 'lvchange')

- it DOES NOT show any runtime state and has nothing in common with physical 'writable' state of a device (and will not be extended for this).

Note - we also do not detect for i.e. linear device if you would switch your underlying device stack to be a non-writable.

ATM we only print warning about inspection needed but we should show some LV Health state showing current info about pool fullness.

LV Write Access will remain to show metadata stored state.

Alasdair Kergon wrote in comment 3:
> I'm confused - you say lvs and lvdisplay show different information, but they
> both show the same there - w = read/write.

From my point of view, the current `lvs` tool reports *different kind* of the
information compared to the `lvdisplay`. See an example from the description of
this BZ:

~~~
# lvs -a
WARNING: /dev/vg/test: Thin's thin-pool needs inspection.
LV              VG         Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
POOL            vg         twi-cotzM-  20.00g             0.00   98.83 
~~~

The attributes reported here are: `twi-cotzM-`, looking in the lvs(8) manpage
(see `The lv_attr bits are:` section there), it means:

 * Volume  type: (t)hin pool
 * Permissions: (w)riteable
 * Allocation  policy: (i)nherited
 * State: thin-pool (c)heck needed
 * device (o)pen
 * Target type: (t)hin
 * Newly-allocated data blocks are overwritten with blocks of (z)eroes before use
 * Volume Health: (M)etadata read only (Related to Thin pool Logical Volumes)

Which is ok: (w)riteable permissions are not a writeable status and the
actual status (check needed, metadata read only) is reported.

So I don't have a problem with current version of `lvs` tool.

But let's see an output of `lvdisplay` command here (again, from the
description of this BZ):

~~~
# lvdisplay vg/test
  WARNING: /dev/vg/test: Thin's thin-pool needs inspection.
  ...
  VG Write Access             read/write
  ...
~~~

And here we see `read/write` state. Which *is not actually true anymore*
(see the explanation given by  Roman Bednář in comment 4).

Zdenek Kabelac in comment 5 wrote:
> LV Write Access
> - it shows the mode used when activating devices (as it is physically store
>   in metadata and is supposed to be change by 'lvchange')
> - it DOES NOT show any runtime state and has nothing in common with physical
>   'writable' state of a device (and will not be extended for this).

So if you say that this actually means somehting else than my first impression
is, this needs to be documented somewhere.

While the current lvdisplay(8) manpage states: `lvs(8) is recommended over
lvdisplay`, the limitation you mention is not directly described here. Moreover
I don't see any description of "LV Write Access" column. I wasn't able to find
any description of "LV Write Access" field of `lvdisplay` in "RHEL 6 LVM
Administrator Guide" either.

So I would say that we have a 2 types of work to be done here:

 * update manpage/docs a bit
 * add new field like Health or something like that to lvdisplay
   tool as suggested by Zdenek Kabelac in comment 2

Red Hat Enterprise Linux 6 is in the Production 3 Phase. During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available.

The official life cycle policy can be reviewed here:

http://redhat.com/rhel/lifecycle

This issue does not meet the inclusion criteria for the Production 3 Phase and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Note that a strong business justification will be required for re-evaluation. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL:

https://access.redhat.com/