Re: [PATCH] Increased upper limit on lists of pool names

[Jesse Cook <crashenx@xxxxxxxxx>]

Just to clarify, you would like to see:

v0.9.10 pre-patch client talk to v0.9.10 patch server

v0.9.10 patch client talk to v0.9.10 pre-patch server

Would the test code I used in my cover letter be sufficient?  If so, I could probably test this fairly easily and quickly today.

On Thu, Mar 15, 2012 at 5:14 AM, Daniel P. Berrange <berrange@xxxxxxxxxx> wrote:

On Wed, Mar 14, 2012 at 08:42:35PM -0500, Jesse J. Cook wrote:
> 256 (8 bits) is insufficient for large scale deployments. 65536 (16 bits) is a
> more appropriate limit and should be sufficient. You are more likely to run
> into other system limitations first, such as the 31998 inode link limit on
> ext3.
> ---
>  src/remote/remote_protocol.x |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/src/remote/remote_protocol.x b/src/remote/remote_protocol.x
> index 59774b2..58f0871 100644
> --- a/src/remote/remote_protocol.x
> +++ b/src/remote/remote_protocol.x
> @@ -103,7 +103,7 @@ const REMOTE_INTERFACE_NAME_LIST_MAX = 256;
>  const REMOTE_DEFINED_INTERFACE_NAME_LIST_MAX = 256;
>
>  /* Upper limit on lists of storage pool names. */
> -const REMOTE_STORAGE_POOL_NAME_LIST_MAX = 256;
> +const REMOTE_STORAGE_POOL_NAME_LIST_MAX = 65536;
>
>  /* Upper limit on lists of storage vol names. */
>  const REMOTE_STORAGE_VOL_NAME_LIST_MAX = 1024;

We have to think about what the compatibility implications are for
this kind of change. eg what is the behaviour when old client talks
to new server, and vica-verca.  It might be fine, but I'd like someone
to enumerate the before & after behaviour in all combinations.


Regards,
Daniel
--
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list