<p dir="ltr"><br>
23 сент. 2015 г. 16:18 пользователь "Daniel P. Berrange" <<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>> написал:<br>
><br>
> On Wed, Sep 23, 2015 at 03:20:51PM +0300, Vasiliy Tolstov wrote:<br>
> > 2015-09-23 14:54 GMT+03:00 Daniel P. Berrange <<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>>:<br>
> > > How have you actually tested this in practice - your patch does<br>
> > > not change any code to make use of this new feate. You're changing<br>
> > > the public API which suggests you expect the client apps to use<br>
> > > this when passing a virStreamPtr to the virStorageVolDownload<br>
> > > method, but the stream client apps pass is not backed by a<br>
> > > virFDStream object. Only libvirtd uses the virFDSteam objects<br>
> > > and you've not changed anything to make use ot that. So this is<br>
> > > all rather strange still. Can you more clearly state what you<br>
> > > are expecting to do.<br>
> ><br>
> ><br>
> > As i'm understand client create stream via virStreamNew , when user<br>
> > invoke virStoreVolDownload this function use created stream.<br>
> > If i'm correct, libvirt when read/write in<br>
> > virStoreVolDownload/virStoreVolUpload uses fdstream functions<br>
> > internally. So data compressed or decompressed.<br>
> > Or when client create virStreamNew and pass it libvirt not always use<br>
> > fdstream functions ?<br>
><br>
> It is not quite that simple because we have a client/server architecture.<br>
><br>
> So the client app creates a virStreamPtr. This is used by the remote<br>
> driver, via a virNetClientStream object to tunnel data over the<br>
> libvirtd connection.<br>
></p>
<p dir="ltr">So client can't say what stream libvirtd need to create for storage driver?</p>
<p dir="ltr">> The libvirtd daemon then creates another virStreamPtr object. This is<br>
> used by the straoge driver, via the virFDStream object to fetch the<br>
> data the client is requesting.<br>
><br>
> So having the client app request compression on its virStreamPtr<br>
> does not work, because that stream object is not the one used<br>
> by the virFDStream code.<br>
><br>
> An alternative approach would be to not try to change the stream API<br>
> at all.<br>
><br>
> Instead pass flags to the virStorageVolDownload/Upload functions,<br>
> eg VIR_STORAGE_VOL_STREAM_COMPRESS_ZLIB. This flag would get passed<br>
> across to the storage driver, which can then turn on compression in<br>
> the virFDStream impl. This would require<br>
><br>
>  - Add the enum flags to include/libvirt/libvirt-storage.h<br>
>  - Add libarchive support to src/fdstream.c<br>
>  - Handle the new flags in src/storage/storage_driver.c to<br>
>    turn on the libarchive compression in fdsream.c<br>
><br>
> Regards,<br>
> Daniel<br>
> --<br>
> |: <a href="http://berrange.com">http://berrange.com</a>      -o-    <a href="http://www.flickr.com/photos/dberrange/">http://www.flickr.com/photos/dberrange/</a> :|<br>
> |: <a href="http://libvirt.org">http://libvirt.org</a>              -o-             <a href="http://virt-manager.org">http://virt-manager.org</a> :|<br>
> |: <a href="http://autobuild.org">http://autobuild.org</a>       -o-         <a href="http://search.cpan.org/~danberr/">http://search.cpan.org/~danberr/</a> :|<br>
> |: <a href="http://entangle-photo.org">http://entangle-photo.org</a>       -o-       <a href="http://live.gnome.org/gtk-vnc">http://live.gnome.org/gtk-vnc</a> :|<br>
</p>