<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 20, 2016 at 1:40 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"><div><div class="gmail-h5"><br></div></div>
Hi<br>
<br>
Please provide listing of all your 'multipath' leg devices - are<br>
they support TRIM ?<br>
Then 'check' dm device.<br>
<br>
See (and attach)<br>
<br>
grep "" /sys/block/*/queue/discard_gra<wbr>nularity<br>
<br>
<br>
Also make sure you are NOT using 'ext2' filesystem which does not support discard on RHEL6 and you are on latest available RHEL6 kernel.<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">Hello,</div><div class="gmail_extra">thanks for answer.</div><div class="gmail_extra">I'm using ext3 filesystem that supports discard.</div><div class="gmail_extra">Currently I'm on this kernel</div><div class="gmail_extra"> </div><div class="gmail_extra"><div class="gmail_extra">[root@dbatest1 ~]# uname -r</div><div class="gmail_extra">2.6.32-431.29.2.el6.x86_64</div><div class="gmail_extra">[root@dbatest1 ~]# </div><div><br></div><div><br></div><div><div>It seems that I was myself able to find a way to online refresh the logical volume and so to successfully run fstrim command against the related file system, without deactivating the lv and most important without generating downtime for my users.</div><div>Please note that what I'm doing is working on a test system where I have the same situation as in production.</div><div>Can you certify my approach and comment about it, so that I can eventually apply in production?</div><div><br></div><div>At the end the logical volume itself is a dm device.</div><div>In my case</div><div><br></div><div>current situation:</div><div>[root@dbatest1 ~]# fstrim /ALM/rdoffline</div><div>fstrim: /ALM/rdoffline: FITRIM ioctl failed: Operation not supported</div><div>[root@dbatest1 ~]#</div><div><br></div><div>[root@dbatest1 ~]# ll /dev/VG_ALMTEST_RDOF/LV_ALMTEST_RDOF </div><div>lrwxrwxrwx 1 root root 7 Oct 20 10:39 /dev/VG_ALMTEST_RDOF/LV_ALMTEST_RDOF -> ../dm-4</div><div>[root@dbatest1 ~]#</div><div><br></div><div>So I can "manipulate" it with dmsetup command.</div><div><br></div><div>[root@dbatest1 ~]# dmsetup info /dev/dm-4</div><div>Name: VG_ALMTEST_RDOF-LV_ALMTEST_RDOF</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, 4</div><div>Number of targets: 1</div><div>UUID: LVM-yOzMkHqmlu9yJuNVWqLVNAx37BwOknEoysZeo9HhzO4P0tETT4WH3RVxNCBeQgRF</div><div><br></div><div>[root@dbatest1 ~]# </div><div><br></div><div>[root@dbatest1 ~]# dmsetup status /dev/dm-4</div><div>0 104849408 linear </div><div>[root@dbatest1 ~]#</div><div><br></div><div>In practice I work as if I had to resize the device, but specifying the same table and reloading the dm device.</div><div><br></div><div>I save the table into a file</div><div>[root@dbatest1 ~]# dmsetup table /dev/dm-4 > my_dm_table</div><div>[root@dbatest1 ~]# </div><div><br></div><div>I reload the dm device specifying the same table; I read in some doc references that they tend to suspend the device, before reloading and then resume, running all the three commands in sequence. I don't know if it is the best approach....</div><div><br></div><div>[root@dbatest1 ~]# dmsetup suspend /dev/dm-4 ; dmsetup reload /dev/dm-4 my_dm_table ; dmsetup resume /dev/dm-4</div><div>[root@dbatest1 ~]# echo $?</div><div>0</div><div>[root@dbatest1 ~]#</div><div><br></div><div>And now the magic:</div><div><br></div><div>[root@dbatest1 ~]# fstrim /ALM/rdoffline</div><div>[root@dbatest1 ~]# echo $?</div><div>0</div><div>[root@dbatest1 ~]# </div><div><br></div><div>Can you give a feedback?</div><div>Thanks,</div><div>Gianluca</div></div></div></div>