search for: vixdisklibinfo

...def uint64_t VixError; #define VIXDISKLIB_FLAG_OPEN_READ_ONLY 4 #define VIXDISKLIB_SECTOR_SIZE 512 +#define VIXDISKLIB_MIN_CHUNK_SIZE 128 +#define VIXDISKLIB_MAX_CHUNK_NUMBER (512*1024) + typedef void *VixDiskLibConnection; typedef void *VixDiskLibHandle; @@ -124,4 +127,14 @@ typedef struct VixDiskLibInfo { char *uuid; } VixDiskLibInfo; +typedef struct { + uint64_t offset; + uint64_t length; +} VixDiskLibBlock; + +typedef struct { + uint32_t numBlocks; + VixDiskLibBlock blocks[1]; +} VixDiskLibBlockList; + #endif /* NBDKIT_VDDK_STRUCTS_H */ diff --git a/plugins/vddk/vddk.c b/plugins/vddk/...

...andle handle) +{ + return "file"; +} + +VixError +VixDiskLib_Close (VixDiskLibHandle handle) +{ + return VIX_OK; +} + +VixError +VixDiskLib_Disconnect (VixDiskLibConnection connection) +{ + return VIX_OK; +} + +VixError +VixDiskLib_GetInfo (VixDiskLibHandle handle, + VixDiskLibInfo **info) +{ + *info = calloc (1, sizeof (struct VixDiskLibInfo)); + (*info)->capacity = CAPACITY; + return VIX_OK; +} + +void +VixDiskLib_FreeInfo (VixDiskLibInfo *info) +{ + free (info); +} + +VixError +VixDiskLib_Read (VixDiskLibHandle handle, + uint64_t start_sector, uint64...

Probably needs a bit of cleanup, but seems like it is generally the right direction. One thing I've noticed is that the expect test randomly (but rarely) hangs :-( I guess something is racey but I don't know what at the moment. Rich.

I believe this roughly implements Nir's proposal here: https://www.redhat.com/archives/libguestfs/2020-August/msg00028.html Unfortunately it doesn't work for me. It actually slows things down quite a lot, for reasons I don't understand. Note the adjustment of the pool-max parameter and how it affects the total time. The results are quite reproducible. $ ./nbdkit -r -U - vddk

...nd); + pthread_mutex_destroy (&h->vddk_handles_lock); free (h); } @@ -639,13 +746,14 @@ vddk_close (void *handle) static int64_t vddk_get_size (void *handle) { - struct vddk_handle *h = handle; + struct handle *h = handle; + GET_VDDK_HANDLE_FOR_CURRENT_SCOPE (h, vddk_handle); VixDiskLibInfo *info; VixError err; uint64_t size; DEBUG_CALL ("VixDiskLib_GetInfo", "handle, &info"); - err = VixDiskLib_GetInfo (h->handle, &info); + err = VixDiskLib_GetInfo (vddk_handle, &info); if (err != VIX_OK) { VDDK_ERROR (err, "VixDiskLib_GetI...

Not sure what version we're up to, but this reimplements extents using the new simpler structure described in this thread: https://www.redhat.com/archives/libguestfs/2019-March/msg00077.html I also fixed most of the things that Eric pointed out in the previous review, although I need to go back over his replies and check I've got everything. This needs a bit more testing. However the

...s_lock); > free (h); > } > > @@ -639,13 +746,14 @@ vddk_close (void *handle) > static int64_t > vddk_get_size (void *handle) > { > - struct vddk_handle *h = handle; > + struct handle *h = handle; > + GET_VDDK_HANDLE_FOR_CURRENT_SCOPE (h, vddk_handle); > VixDiskLibInfo *info; > VixError err; > uint64_t size; > > DEBUG_CALL ("VixDiskLib_GetInfo", "handle, &info"); > - err = VixDiskLib_GetInfo (h->handle, &info); > + err = VixDiskLib_GetInfo (vddk_handle, &info); > if (err != VIX_OK) { >...

I'm not sure exactly which version we're up to, but let's say it's version 4. I'm a lot happier with this version: - all filters have been reviewed and changed where I think that's necessary - can_extents is properly defined and implemented now - NBD protocol is followed - I believe it addresses all previous review points where possible The "only" thing

I want to post this but mainly for discussion and early review. It's not safe for these patches to all go upstream yet (because not all filters have been checked/adjusted), but if any patches were to go upstream then probably 1 & 2 only are safe. File, VDDK, memory and data plugins all work, although I have only done minimal testing on them. The current tests, such as they are, all

This has already been pushed upstream. I am simply posting these here so we have a reference in the mailing list in case we find bugs later (as I'm sure we will - it's a complex patch series). Great thanks to Eric Blake for tireless review on this one. It also seems to have identified a few minor bugs in qemu along the way. Rich.