[dm-devel] [RFC] disk doesn't spin down with thin pool + dmeventd

[Alan Jenkins]

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