On Wed, Nov 05 2014 at 8:05am -0500,
Mikulas Patocka <mpatocka@xxxxxxxxxx> wrote:
>
>
> On Wed, 5 Nov 2014, Mikulas Patocka wrote:
>
> > You can for example set the flag in the prison meaning that the prison is
> > suspended and then call dm_internal_suspend immediatelly followed by
> > dm_internal_resume - that will clear in-progress bios and prevent new bios
> > from coming in (and we don't need to change dm_internal_suspend and
> > dm_internal_resume to become so big).
It may _seem_ like they have gotten big given the code was refactored to
share code with dm_suspend and dm_resume. BUT I know you see that the
actual code complexity isn't big. I especially wanted you (and/or Bryn)
to evaluate the performance implications that my changes had on
dm-stats. I'm pretty confident there won't be much if any performance
difference (given the code is identical to what you had, except some
extra checks are made but ultimately not used, e.g. lockfs/unlockfs).
The end result of the dm_internal_{suspend,resume} changes is an
interface that is useful for DM targets in addition to dm-stats. That
is the kind of advancement DM needs.
Please focus on the performance impact of my changes, if any, and we'll
go from there.
> No, the correct sequence is this (do this in presuspend handler):
>
> 1. call dm_internal_suspend on all thin devices
> 2. set the flag in the prison meaning that the prison is blocked
> 3. call dm_internal_resume on all thin devices
I really didn't like the idea of reusing the bio-prison to achieve the
suspend of all thins to begin with. This proposal is even more suspect
given the desire to call dm_internal_suspend and dm_internal_resume from
pool_presuspend.
It just isn't code that I want to see making its way into the tree.
Sets bad precedent of hacking around problems within a target for
questionable gain (questionable in that there really isn't a
pattern/infrastructure for other more complex targets to follow so
they'd need to invent their own hack should they have a comparable
problem).
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
