options: Report image format and virtual size #6
Conversation
nirs
added
enhancement
aesteve-rh
force-pushed
the
options-size
branch
2 times, most recently
from
c647a60
to
79b3aee
Compare
Import and use units constants in the test to improve readability. Signed-off-by: Albert Esteve <[email protected]>
aesteve-rh
force-pushed
the
options-size
branch
from
79b3aee
to
d5df688
Compare
Fix small typo on extents example. Signed-off-by: Albert Esteve <[email protected]>
Report image virtual size in OPTIONS so clients can get the image size without a possibly slow extent call. Report the format since OPTIONS can report the virtual size only when the backend provides raw format. This is used when using the http backend to report OPTIONS to the client. Reporting virtual size is easy with the nbd and memory backends since they always use raw format. When using file backend and qcow2 image, we don't have access to the image virtual size, and this size is not helpful to the user uploading or downloading data. Currently we don't know about the image format since engine does not report it in the ticket. The http backend reports the info from the remote server, so it depends on the backend used by the remote server, and on having new server reporting the format and size. To keep code and the API simple, we report virtual size only when using the nbd and memory backends. When engine will report the image format for the file backend, we can also report the size for raw images access via the file backend. Change-Id: I89118301c98dc2d11c25a4d1e7ef83df26336f01 Related: oVirt#67 Bug-Url: https://bugzilla.redhat.com/1924945 Signed-off-by: Nir Soffer <[email protected]>
aesteve-rh
force-pushed
the
options-size
branch
from
d5df688
to
32e6573
Compare
|
@nirs I have done some tests and can see the new options available when I run an example server locally, with a nbd backend. It looks correct. But unfortunately I haven't been able to do any test showing any relevant speedup. It downloads at roughly the same speed as master branch. Tried two methods: with direct download with a GET request, and through the client using the I would like to have some data to share before ready this PR up, but I'm not sure what else can I try to obtain it, or what I may be missing in my own local testing. |
|
@aesteve-rh with download you will not see any difference, since we always get extents once. You should see a difference with incremental backup. With current release we get extent twice, |
|
Let’s close since it stale for long time. |
Report image virtual size in OPTIONS so clients can get the image size
without a possibly slow extent call.
Report the format since OPTIONS can report the virtual size only when
the backend provides raw format. This is used when using the http
backend to report OPTIONS to the client.
Reporting virtual size is easy with the nbd and memory backends since
they always use raw format.
When using file backend and qcow2 image, we don't have access to the
image virtual size, and this size is not helpful to the user uploading
or downloading data. Currently we don't know about the image format
since engine does not report it in the ticket.
The http backend reports the info from the remote server, so it depends
on the backend used by the remote server, and on having new server
reporting the format and size.
To keep code and the API simple, we report virtual size only when using
the nbd and memory backends. When engine will report the image format
for the file backend, we can also report the size for raw images access
via the file backend.
This is work in progress, exploring the needed changes. I will post a
cleaner version later.