> > This approach could still surprise the storage-admin when glusterfs(d) > > processes > > bind to ports in the range where brick ports are being assigned. We should > > make this > > predictable by reserving brick ports setting > > net.ipv4.ip_local_reserved_ports. > > Initially reserve 50 ports starting at 49152. Subsequently, we could > > reserve ports on demand, > > say 50 more ports, when we exhaust previously reserved range. > > net.ipv4.ip_local_reserved_ports > > doesn't interfere with explicit port allocation behaviour. i.e if the > > socket uses > > a port other than zero. With this option we don't have to manage ports > > assignment at a process > > level. Thoughts? > If the reallocation can be done on demand, I do think this is a better > approach to tackle this problem. We could fix the predictability aspect in a different patch. This patch, where we assign ports starting from 65335 in descending order, can be reviewed independently. _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
