Print

Print


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