diff mbox series

[v5,16/16] blockdev: document transactional shortcomings

Message ID 20180906130225.5118-17-jsnow@redhat.com
State New
Headers show
Series jobs: Job Exit Refactoring Pt 2 | expand

Commit Message

John Snow Sept. 6, 2018, 1:02 p.m. UTC
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 <jsnow@redhat.com>
---
 blockdev.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

Comments

Jeff Cody Sept. 6, 2018, 5:03 p.m. UTC | #1
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 <jsnow@redhat.com>

Reviewed-by: Jeff Cody <jcody@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
>
Max Reitz Sept. 7, 2018, 11:23 p.m. UTC | #2
On 2018-09-06 15:02, 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 <jsnow@redhat.com>
> ---
>  blockdev.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)

Reviewed-by: Max Reitz <mreitz@redhat.com>
diff mbox series

Patch

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.
+     */
 };
 
 /**