Linux Device Mapper development
 help / color / mirror / Atom feed
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

  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