Dne 5.11.2014 v 15:37 Mikulas Patocka napsal(a):
On Wed, 5 Nov 2014, Mike Snitzer wrote:
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).
This is not about performance, it is about unclear behavior.
If someone does internal_suspend followed by remove, what should be the
correct behavior? The current code deadlocks in this case.
yep - that would my concern as well.
If this 'internal' suspend is purely 'enforced' by incorrectly behaving user
space part (aka lvm2 is not doing it's best) I assume it's better to fix
user space - instead of moving it into kernel with some side-effects.
Zdenek
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
