From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alan Jenkins Subject: Re: [RFC] disk doesn't spin down with thin pool + dmeventd Date: Sat, 9 Jan 2016 10:07:45 +0000 Message-ID: <5690DBF1.6020409@gmail.com> References: <568EBD08.70800@gmail.com> Reply-To: device-mapper development Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <568EBD08.70800@gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: dm-devel@redhat.com List-Id: dm-devel.ids 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