On Thu, Oct 20, 2016 at 1:40 PM, Zdenek Kabelac <zkabe...@redhat.com> wrote:
> > Hi > > Please provide listing of all your 'multipath' leg devices - are > they support TRIM ? > Then 'check' dm device. > > See (and attach) > > grep "" /sys/block/*/queue/discard_granularity > > > Also make sure you are NOT using 'ext2' filesystem which does not support > discard on RHEL6 and you are on latest available RHEL6 kernel. > > > Regards > > Zdenek > > > Hello, thanks for answer. I'm using ext3 filesystem that supports discard. Currently I'm on this kernel [root@dbatest1 ~]# uname -r 2.6.32-431.29.2.el6.x86_64 [root@dbatest1 ~]# 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. Please note that what I'm doing is working on a test system where I have the same situation as in production. Can you certify my approach and comment about it, so that I can eventually apply in production? At the end the logical volume itself is a dm device. In my case current situation: [root@dbatest1 ~]# fstrim /ALM/rdoffline fstrim: /ALM/rdoffline: FITRIM ioctl failed: Operation not supported [root@dbatest1 ~]# [root@dbatest1 ~]# ll /dev/VG_ALMTEST_RDOF/LV_ALMTEST_RDOF lrwxrwxrwx 1 root root 7 Oct 20 10:39 /dev/VG_ALMTEST_RDOF/LV_ALMTEST_RDOF -> ../dm-4 [root@dbatest1 ~]# So I can "manipulate" it with dmsetup command. [root@dbatest1 ~]# dmsetup info /dev/dm-4 Name: VG_ALMTEST_RDOF-LV_ALMTEST_RDOF State: ACTIVE Read Ahead: 256 Tables present: LIVE Open count: 1 Event number: 0 Major, minor: 253, 4 Number of targets: 1 UUID: LVM-yOzMkHqmlu9yJuNVWqLVNAx37BwOknEoysZeo9HhzO4P0tETT4WH3RVxNCBeQgRF [root@dbatest1 ~]# [root@dbatest1 ~]# dmsetup status /dev/dm-4 0 104849408 linear [root@dbatest1 ~]# In practice I work as if I had to resize the device, but specifying the same table and reloading the dm device. I save the table into a file [root@dbatest1 ~]# dmsetup table /dev/dm-4 > my_dm_table [root@dbatest1 ~]# 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.... [root@dbatest1 ~]# dmsetup suspend /dev/dm-4 ; dmsetup reload /dev/dm-4 my_dm_table ; dmsetup resume /dev/dm-4 [root@dbatest1 ~]# echo $? 0 [root@dbatest1 ~]# And now the magic: [root@dbatest1 ~]# fstrim /ALM/rdoffline [root@dbatest1 ~]# echo $? 0 [root@dbatest1 ~]# Can you give a feedback? Thanks, Gianluca
-- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
