| Message ID | 1343219765-12297-2-git-send-email-benoit@irqsave.net |
|---|---|
| State | New |
| Headers | show |
On 07/25/2012 06:36 AM, benoit.canet@gmail.com wrote: > From: Benoît Canet <benoit@irqsave.net> > > Create bdrv_get_backing_file_ancestors_count() in order to be > able to show in QMP and HMP how many ancestors backing an image a > block device have. > > Signed-off-by: Benoit Canet <benoit@irqsave.net> > --- > block.c | 13 +++++++++++++ > block.h | 1 + > 2 files changed, 14 insertions(+) > > diff --git a/block.c b/block.c > index ce7eb8f..03e0860 100644 > --- a/block.c > +++ b/block.c > @@ -2754,6 +2754,19 @@ BlockDriverState *bdrv_find_backing_image(BlockDriverState *bs, > return NULL; > } > > +int bdrv_get_backing_file_ancestors_count(BlockDriverState *bs) > +{ > + if (!bs->drv) { > + return 0; > + } > + > + if (!bs->backing_hd) { > + return 0; > + } > + > + return 1 + bdrv_get_backing_file_ancestors_count(bs->backing_hd); Is there any risk of stack overflow for a hugely nested setup? Then again, I suspect you are going to run into other issues if you are nested that deeply, before this recursion could cause overflow worth worrying about. This is an O(n) operation; is it worth storing the nesting depth as part of a BlockDriverState to turn it into an O(1) operation? That is, you already have to do the O(n) traversal once when originally opening the chain, so why not have opening the chain populate a struct member with how deep the opening went, so that all future queries can just return that struct member. Of course, you then run into the issue that operations that change the depth (snapshot, block streaming, and the proposed block commit) would then be O(n) to adjust the counts of every member of the chain, instead of O(1) because the count is computed on the fly. Just food for thought, and not a technical reason requiring you to rewrite the patch unless you really like the idea.
Le Wednesday 25 Jul 2012 à 10:27:09 (-0600), Eric Blake a écrit : > On 07/25/2012 06:36 AM, benoit.canet@gmail.com wrote: > > From: Benoît Canet <benoit@irqsave.net> > > > > Create bdrv_get_backing_file_ancestors_count() in order to be > > able to show in QMP and HMP how many ancestors backing an image a > > block device have. > > > > Signed-off-by: Benoit Canet <benoit@irqsave.net> > > --- > > block.c | 13 +++++++++++++ > > block.h | 1 + > > 2 files changed, 14 insertions(+) > > > > diff --git a/block.c b/block.c > > index ce7eb8f..03e0860 100644 > > --- a/block.c > > +++ b/block.c > > @@ -2754,6 +2754,19 @@ BlockDriverState *bdrv_find_backing_image(BlockDriverState *bs, > > return NULL; > > } > > > > +int bdrv_get_backing_file_ancestors_count(BlockDriverState *bs) > > +{ > > + if (!bs->drv) { > > + return 0; > > + } > > + > > + if (!bs->backing_hd) { > > + return 0; > > + } > > + > > + return 1 + bdrv_get_backing_file_ancestors_count(bs->backing_hd); > > Is there any risk of stack overflow for a hugely nested setup? Then > again, I suspect you are going to run into other issues if you are > nested that deeply, before this recursion could cause overflow worth > worrying about. > I don't know. > This is an O(n) operation; is it worth storing the nesting depth as part > of a BlockDriverState to turn it into an O(1) operation? That is, you > already have to do the O(n) traversal once when originally opening the > chain, so why not have opening the chain populate a struct member with > how deep the opening went, so that all future queries can just return > that struct member. Of course, you then run into the issue that > operations that change the depth (snapshot, block streaming, and the > proposed block commit) would then be O(n) to adjust the counts of every > member of the chain, instead of O(1) because the count is computed on > the fly. Just food for thought, and not a technical reason requiring > you to rewrite the patch unless you really like the idea. Hello, I agree that 0(1) would be way better but wouldn't it increase further the know how required to touch the block layer. (I think about newcomers like me implementing another feature requiring to change the depth and not being aware of this obligation) Benoît > > -- > Eric Blake eblake@redhat.com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org >
diff --git a/block.c b/block.c index ce7eb8f..03e0860 100644 --- a/block.c +++ b/block.c @@ -2754,6 +2754,19 @@ BlockDriverState *bdrv_find_backing_image(BlockDriverState *bs, return NULL; } +int bdrv_get_backing_file_ancestors_count(BlockDriverState *bs) +{ + if (!bs->drv) { + return 0; + } + + if (!bs->backing_hd) { + return 0; + } + + return 1 + bdrv_get_backing_file_ancestors_count(bs->backing_hd); +} + #define NB_SUFFIXES 4 char *get_human_readable_size(char *buf, int buf_size, int64_t size) diff --git a/block.h b/block.h index c89590d..5b1ba2b 100644 --- a/block.h +++ b/block.h @@ -174,6 +174,7 @@ int coroutine_fn bdrv_co_is_allocated_above(BlockDriverState *top, int nb_sectors, int *pnum); BlockDriverState *bdrv_find_backing_image(BlockDriverState *bs, const char *backing_file); +int bdrv_get_backing_file_ancestors_count(BlockDriverState *bs); int bdrv_truncate(BlockDriverState *bs, int64_t offset); int64_t bdrv_getlength(BlockDriverState *bs); int64_t bdrv_get_allocated_file_size(BlockDriverState *bs);