<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 25, 2016 at 4:12 PM, Zdenek Kabelac <span dir="ltr"><<a href="mailto:zkabelac@redhat.com" target="_blank">zkabelac@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="gmail-h5"><br>
</div></div></blockquote><span class="gmail-">
t giving downtime, in a safe way.<br>
<br>
<br></span>
Normally it's not advised to use 'dmsetup' command for LV.<br>
The above sequence should be equivalent to:<br>
<br>
lvchange --refresh vg/lv<br>
(or vgchange --refresh vg - doing it for every active LV in VG)<br>
<br>
It's unclear how this could help - unless you we doing some 'pvmove'<br>
operations (which might be worth a BZ).<br>
<br>
You should collect all states while it 'DOES NOT' work.<br>
And then run the --refresh (which you thing it's fixing it for your)<br>
ATM I'm clueless how you get mapping without TRIM where --refresh can fix it.<br>
<br>
<br>
Regards<span class="gmail-HOEnZb"><font color="#888888"><br>
<br>
Zdenek<br>
<br>
<br>
</font></span></blockquote></div><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">When I rescan the single devices (the legs) I do have then </div><div class="gmail_extra"><div class="gmail_extra">[root@dbatest1 ~]# for dev in sdea sdem ; do grep "" /sys/block/${dev}/queue/discard_granularity; done</div><div class="gmail_extra">1048576</div><div class="gmail_extra">1048576</div><div class="gmail_extra">[root@dbatest1 ~]#</div><div class="gmail_extra"><br></div><div class="gmail_extra">But the problem is the device mapper device of the LV itself, while the multipath one is ok.</div><div class="gmail_extra">I had tried with both </div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">vgchange --refresh VG_TEST_REDO<br></div><div class="gmail_extra">and</div><div class="gmail_extra">lvchange --refresh VG_TEST_REDO/LV_TEST_REDO<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">BTW: The VG contains only this LV</div><div class="gmail_extra"><br></div><div class="gmail_extra">yes the current device has been the target of a pvmove operation, where initially the LUN was not configured as thin provisioned.</div><div class="gmail_extra"><br></div><div class="gmail_extra">but the underlying dm device still contains 0 in its granularity. And the fstrim command fails.</div><div class="gmail_extra">in this new test it is dm-14 (while the multipath device of the related PV is dm-47 and it is ok)</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">[root@dbatest1 ~]# multipath -l /dev/mapper/3600a098038303769752b4951473778673600a098038303769752b495147377867 dm-47 NETAPP,LUN C-Mode</div><div class="gmail_extra">size=2.0G features='4 queue_if_no_path pg_init_retries 50 retain_attached_hw_handle' hwhandler='1 alua' wp=rw</div><div class="gmail_extra">`-+- policy='round-robin 0' prio=0 status=active</div><div class="gmail_extra"> |- 7:0:5:21 sdea 128:32 active undef running</div><div class="gmail_extra"> `- 8:0:5:21 sdem 128:224 active undef running</div><div class="gmail_extra">[root@dbatest1 ~]# </div><div><br></div></div></div><div class="gmail_extra"><div class="gmail_extra">[root@dbatest1 ~]# ll /dev/VG_TEST_REDO/LV_TEST_REDO</div><div class="gmail_extra">lrwxrwxrwx 1 root root 8 Oct 25 17:25 /dev/VG_TEST_REDO/LV_TEST_REDO -> ../dm-14</div><div class="gmail_extra">[root@dbatest1 ~]#</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div><div class="gmail_extra"><div class="gmail_extra">[root@dbatest1 ~]# cat /sys/block/dm-47/queue/discard_granularity</div><div class="gmail_extra">1048576</div><div class="gmail_extra">[root@dbatest1 ~]# </div><div><br></div><div><br></div><div><div>[root@dbatest1 ~]# cat /sys/block/dm-14/queue/discard_granularity</div><div>0</div><div>[root@dbatest1 ~]#</div></div><div><br></div><div>So the problem seems to find a way to get the discard_granularity inside dm-14.</div><div>One way to obtain it is my method:</div><div><br></div><div><div>[root@dbatest1 ~]# dmsetup info /dev/dm-14</div><div>Name: VG_TEST_REDO-LV_TEST_REDO</div><div>State: ACTIVE</div><div>Read Ahead: 256</div><div>Tables present: LIVE</div><div>Open count: 1</div><div>Event number: 0</div><div>Major, minor: 253, 14</div><div>Number of targets: 1</div><div>UUID: LVM-ebT3iin7JZdFZCoR05NEPpXcDosNQ3Y46HwejMdu0o9qfeeeMcRTemcuGtUVqMds</div><div><br></div></div><div>[root@dbatest1 ~]# dmsetup table /dev/dm-14 > my_dm_table<br></div><div><br></div><div><div>[root@dbatest1 ~]# dmsetup suspend /dev/dm-14 ; dmsetup reload /dev/dm-14 my_dm_table ; dmsetup resume /dev/dm-14</div><div>[root@dbatest1 ~]#</div></div><div><br></div><div>And now</div><div><div>[root@dbatest1 ~]# cat /sys/block/dm-14/queue/discard_granularity</div><div>1048576</div><div>[root@dbatest1 ~]# </div></div><div><br></div><div>and</div><div><div>[root@dbatest1 ~]# fstrim /TEST/redolog/</div><div>[root@dbatest1 ~]# </div></div><div><br></div></div></div></div>