Hi Pete, Nothing strange with the code as far as I can see. The server's selectioon mask is computed as 1<<(server's login position). So, the first server has a mask of 1, the second 2, the thrdu 4, etc. The mask is never recomputed after that. Instead, and and ord are used to selection purposes. So, I don't immediately see what the number 32 may be all about. Was the redrector on a Intel or Solaris box? If you swap architectures, does the problem go away? Andy ----- Original Message ----- From: "Peter Elmer" <[log in to unmask]> To: <[log in to unmask]>; "Andrew Hanushevsky" <[log in to unmask]> Sent: Saturday, September 11, 2004 9:34 AM Subject: more than 32 data servers with the olbd? > Hi Andy, > > I know that the olbd doesn't support more than 64 server olbd's per manager > (for >64 you suggest that people group them in groups of 64 hierarchically), > but I think there might be a bug for >32 data servers. > > I setup 32 data servers plus a redirector and spread some files around > on the 32 data servers. Here everything seems to work: when I access the > files via the redirector I'm always redirected to the right place. > > I then stopped the servers on the redirector, started 6 additional data > servers (for a total of 38) and restarted the xrootd and olbd on the > redirector. With that setup I sometimes find that the client is redirected to > a machine which doesn't have the file. In the particular example I looked > at it was directed to tori0291 when tori0254 actually has the file. > > I looked at the order in which the server olbd's logged in to the manager > olbd (see (a) below) and a pattern jumps out: the data is on the 5th server > while the client was redirected to the 37th (=32+5). Is there perhaps some bit > shifting or similar set for 32 instead of 64 somewhere? I'm not sure anyone > has yet tried >32 servers. (SLAC currently has 30 in the xrootd pool.) > > (This was with the HEAD of CVS as of right now.) > > Pete > > (a) > > 1 tori0287.slac.stanford.edu > 2 tori0288.slac.stanford.edu > 3 tori0289.slac.stanford.edu > 4 tori0260.slac.stanford.edu > 5 tori0254.slac.stanford.edu ** > 6 tori0282.slac.stanford.edu > 7 tori0252.slac.stanford.edu > 8 tori0277.slac.stanford.edu > 9 tori0272.slac.stanford.edu > 10 tori0262.slac.stanford.edu > 11 tori0255.slac.stanford.edu > 12 tori0275.slac.stanford.edu > 13 tori0280.slac.stanford.edu > 14 tori0278.slac.stanford.edu > 15 tori0267.slac.stanford.edu > 16 tori0251.slac.stanford.edu > 17 tori0284.slac.stanford.edu > 18 tori0276.slac.stanford.edu > 19 tori0286.slac.stanford.edu > 20 tori0263.slac.stanford.edu > 21 tori0253.slac.stanford.edu > 22 tori0264.slac.stanford.edu > 23 tori0281.slac.stanford.edu > 24 tori0283.slac.stanford.edu > 25 tori0274.slac.stanford.edu > 26 tori0258.slac.stanford.edu > 27 tori0270.slac.stanford.edu > 28 tori0257.slac.stanford.edu > 29 tori0271.slac.stanford.edu > 30 tori0268.slac.stanford.edu > 31 tori0265.slac.stanford.edu > 32 tori0259.slac.stanford.edu > 33 tori0266.slac.stanford.edu > 34 tori0285.slac.stanford.edu > 35 tori0261.slac.stanford.edu > 36 tori0290.slac.stanford.edu > 37 tori0291.slac.stanford.edu ** > 38 tori0292.slac.stanford.edu > > ------------------------------------------------------------------------- > Peter Elmer E-mail: [log in to unmask] Phone: +41 (22) 767-4644 > Address: CERN Division PPE, Bat. 32 2C-14, CH-1211 Geneva 23, Switzerland > ------------------------------------------------------------------------- >