On 1/19/23 14:58, Zdenek Kabelac wrote:
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.
Hi Zdenek,
That's great information! Thanks a lot for sharing it.
Regards,
Nikos
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/dm-devel
