[dm-devel] [RFC] disk doesn't spin down with thin pool + dmeventd
Alan Jenkins
alan.christopher.jenkins at gmail.com
Sat Jan 9 11:51:32 UTC 2016
On 09/01/16 10:07, Alan Jenkins wrote:
> 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():
Nevermind. For me, the upstream commit fixes the problem on its own.
The wait task does get run every 10 seconds. But the 10 second timeout
interrupts it before __dev_status() is called. So setting noflush on
the status task, had already fixed the problem.
Thanks
Alan
P.S. if anyone wants to take my comment describing the problem, they're
still welcome :).
/*
* Avoid repeatedly forcing a flush.
*
* Allow the disks to sleep, and accept "out-of-date" statistics.
* E.g. affects thin pools. Commits will occur every second already,
* if the pool state is changing.
*/
More information about the dm-devel
mailing list