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
> -------------------------------------------------------------------------
>
|