On Thu, Sep 06, 2018 at 09:02:25AM -0400, John Snow wrote:
> Presently only the backup job really guarantees what one would consider
> transactional semantics. To guard against someone helpfully adding them
> in the future, document that there are shortcomings in the model that
> would need to be audited at that time.
>
> Signed-off-by: John Snow <js...@redhat.com>
Reviewed-by: Jeff Cody <jc...@redhat.com>
> ---
> blockdev.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/blockdev.c b/blockdev.c
> index 0cf8febe6c..d4b42403df 100644
> --- a/blockdev.c
> +++ b/blockdev.c
> @@ -2182,7 +2182,13 @@ static const BlkActionOps actions[] = {
> .instance_size = sizeof(BlockDirtyBitmapState),
> .prepare = block_dirty_bitmap_disable_prepare,
> .abort = block_dirty_bitmap_disable_abort,
> - }
> + },
> + /* Where are transactions for MIRROR, COMMIT and STREAM?
> + * Although these blockjobs use transaction callbacks like the backup
> job,
> + * these jobs do not necessarily adhere to transaction semantics.
> + * These jobs may not fully undo all of their actions on abort, nor do
> they
> + * necessarily work in transactions with more than one job in them.
> + */
> };
>
> /**
> --
> 2.14.4
>
