Dne 19. 01. 23 v 10:36 Nikos Tsironis napsal(a):
On 1/18/23 18:28, Mike Snitzer wrote:
On Wed, Jan 18 2023 at 7:29P -0500,
Nikos Tsironis <ntsironis@xxxxxxxxxxx> wrote:
Hi Mike,
Thanks for the quick reply.
I couldn't find this constraint documented anywhere and since the
various DM targets seem to allow message operations while the device is
suspended I drew the wrong conclusion.
Hi Nikos
Some notes from lvm2 developer - we work with these constrains:
DM target should not need to allocate bunch of memory while suspended (target
should preallocated pool of some memory if it really needs to do it in this case).
DM target should check and allocate everything it can in the 'load' phase and
error as early as possibly (so loaded inactive table can be cleared/dropped
and 'resume' target can continue its work).
Error in suspend phase is typically the last moment -we can handle failure
'somehow'.
Handling failure in 'resume' is a can of worm with no good solution - so
resume really should do as minimal as possible and should work with everything
already prepared from load & suspend.
'DM status/info' should work while device is suspend - but no allocation
should be needed in this case to produce result.
Sending messages to a suspended target should not be needed - if it is - it
should be most likely solved via 'table reload' change (target design change).
Loading to the inactive table slot should not be break anything for the active
table slot (table clear shall resume at suspend point).
Surely the list could go longer - but these basics are crucial.
Regards
Zdenek
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/dm-devel
