[libvirt] [PATCH] Increased upper limit on lists of pool names
Jesse Cook
crashenx at gmail.com
Thu Mar 15 11:33:22 UTC 2012
On Thu, Mar 15, 2012 at 5:14 AM, Daniel P. Berrange <berrange at redhat.com> 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
> :|
Sorry, I accidentally top-posted my reply originally.
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.
-- Jesse
More information about the libvir-list
mailing list