On 08/01/16 08:17, Zdenek Kabelac wrote:
> Dne 7.1.2016 v 20:31 Alan Jenkins napsal(a):
>> Hi
>>
>> I tried using Docker on my Fedora NAS box. It created a thin pool LV,
>> which
>> caused hard drive activity every ~10 seconds.
>>
>> dmeventd queries the thin pool every 10 seconds, and it causes a
>> transaction
>> commit in order to make sure the statistics are up to date. But
>> transactions
>> are already supposed to be committed after 1 second. (See
>> Documentation/device-mapper/thin-provisioning.txt, "Updating on-disk
>> metadata").
>>
>> It seems like a simple case of "don't do that". The kernel already
>> lets us
>> avoid the commit. How about it (patch below)? If it seems
>> reasonable, I can
>> whip up a commit message for it.
>>
>
> Hi
>
> I believe it's already solved upstream in version 2.02.133
> of lvm2 package with this commit:
>
> 81e9ab3156badecc6a64447708c4ae4886e3c244
> Date: Thu Oct 22 12:36:25 2015 +0200
>
> Which version of lvm2 are you using ?
>
> Regards
>
> Zdenek
Thanks! That explains a question I had.
My patch was based on lvm2 master. The upstream commit applies to the
_status_ task, but I applied dm_task_no_flush() to the _wait_ task:
DM_DEVICE_WAITEVENT / DM_DEV_WAIT_CMD.
I need to test this again, and I shall. (I started testing with version
lvm2-2.02.132-2.fc23.x86_64).
But from the code, it looks like we need *both* patches to fix the
problem. See:
1. dm-ioctl.c: dev_wait() seems to include the exact same code as
dev_table_status, specifically the call to __dev_status():
1192 /*
1193 * The userland program is going to want to know what
1194 * changed to trigger the event, so we may as well tell
1195 * him and save an ioctl.
1196 */
1197 __dev_status(md, param);
1198
1199 table = dm_get_live_or_inactive_table(md, param, &srcu_idx);
1200 if (table)
1201 retrieve_status(table, param, param_size);
1202 dm_put_live_table(md, srcu_idx);
2. Consequently, `dmsetup wait` accepts `--noflush` just like `dmsetup
status` does. (`dmsetup table` could as well, I don't know why it
doesn't, at least not in the documentation).
Thanks again
Alan
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
