From: Alan Jenkins <alan.christopher.jenkins@gmail.com>
To: dm-devel@redhat.com
Subject: Re: [RFC] disk doesn't spin down with thin pool + dmeventd
Date: Sat, 9 Jan 2016 10:07:45 +0000 [thread overview]
Message-ID: <5690DBF1.6020409@gmail.com> (raw)
In-Reply-To: <568EBD08.70800@gmail.com>
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
next prev parent reply other threads:[~2016-01-09 10:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-07 19:31 [RFC] disk doesn't spin down with thin pool + dmeventd Alan Jenkins
2016-01-08 8:17 ` Zdenek Kabelac
2016-01-09 10:07 ` Alan Jenkins [this message]
2016-01-09 11:51 ` Alan Jenkins
2016-01-11 9:21 ` Zdenek Kabelac
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5690DBF1.6020409@gmail.com \
--to=alan.christopher.jenkins@gmail.com \
--cc=dm-devel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox