[dm-devel] how to refresh LV to apply fstrim online

Gianluca Cecchi gianluca.cecchi at gmail.com
Thu Oct 20 23:32:06 UTC 2016


On Thu, Oct 20, 2016 at 1:40 PM, Zdenek Kabelac <zkabelac at 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 at dbatest1 ~]# uname -r
2.6.32-431.29.2.el6.x86_64
[root at 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 at dbatest1 ~]# fstrim /ALM/rdoffline
fstrim: /ALM/rdoffline: FITRIM ioctl failed: Operation not supported
[root at dbatest1 ~]#

[root at 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 at dbatest1 ~]#

So I can "manipulate" it with dmsetup command.

[root at 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 at dbatest1 ~]#

[root at dbatest1 ~]# dmsetup status /dev/dm-4
0 104849408 linear
[root at 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 at dbatest1 ~]# dmsetup table /dev/dm-4 > my_dm_table
[root at 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 at dbatest1 ~]# dmsetup suspend /dev/dm-4 ; dmsetup reload /dev/dm-4
my_dm_table ; dmsetup resume /dev/dm-4
[root at dbatest1 ~]# echo $?
0
[root at dbatest1 ~]#

And now the magic:

[root at dbatest1 ~]# fstrim /ALM/rdoffline
[root at dbatest1 ~]# echo $?
0
[root at dbatest1 ~]#

Can you give a feedback?
Thanks,
Gianluca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20161021/54d4ac43/attachment.htm>


More information about the dm-devel mailing list