Hi Derek,
The problem stems from the issue Andreas and I discussed. That is, that
opaque information is not handled for any function other than open(). So,
the opaque information is passed through for other calls (e.g., stat())
which then exhibit the behaviour you see. Whatever the solution, it is
likely to break your existing implementation for Alice filenames. The
possibilities are:
a) Screen out opaque information for all functions that accept a path. Then
pass it to the appropraie function via an opaque argument.
b) Suppress opaque information, except for the open() function.
c) Leave things as they are but let the olbd screen out opaque information.
None of the above are great solution.
(a) forces us to change the whole sfs interface because only open() accepts
opaque information. That was an oversight on our part. However, in making
this change, we would break Alice filenames.
(b) makes some amount of sense since open() is the only thing that really
needs opaque information (well, it being opaque means we really can't tell
where it might get used). However, it *really* makes Alice filenames
unusable in it's current incarnation since the file name is passed via
opaque information. Perhaps it would have been better to use "/alice/<real
alice filename>" instead of opque information. This would have avoided some
nuisances that currently exist in the implementation (e.g., non-uniform
handling of opaque information).
(c) is really a hack fix but is relatively easy to do and breaks the fewest
number of things. However, it still keeps the non-uniform handling of opaque
information.
So, let me know how you would prefer to have this fixed. Personally, maybe
should have never used opaque information to pass Alice filenames. Instead
they should have been encoded in the filename itself leaving opaque
information for other things. Anyway, let me know.
Andy
----- Original Message -----
From: "Derek Feichtinger" <[log in to unmask]>
To: "xrootd mailing list" <[log in to unmask]>
Sent: Monday, April 25, 2005 7:36 AM
Subject: olbd fails to learn when a file disappears from a leaf node, but
another copy still exists
> Hi,
>
> I tested whether this problem had been corrected in the development
> release
> 20050417-0431.
> (original submission:
> http://www.slac.stanford.edu/cgi-bin/lwgate/XROOTD-L/archives/xrootd-l.200504/Author/article-23.html)
>
> It still fails, but with other symptoms.
>
> Setup:
> 1. Two leaf nodes. Both have the file fileA
>
> 2. Reading via the redirector gives me alternatively fileA from leaf1 and
> leaf2.
>
> 3. I remove fileA from leaf1.
>
> 4. When a client request gets redirected to leaf1, the client now
> correctly
> connects back to the manager, who should do an update of this cache entry.
> The master sends out a stat request to the slaves like this:
> statf /tmp/xrootd/all_1&tried=leaf1
> But the node that still has the file seems not to respond in the
> affirmative,
> and it seems the cache is not updated, because...
>
> 5. I'm left with a system that alternately succeeds (from leaf2) and fails
> (via the above route) giving me the file.
>
> Cheers,
> Derek
>
> --
> Dr. Derek Feichtinger Tel: +41 22 767 10 07
> LCG/ARDA Group email: [log in to unmask]
> CERN
> http://people.web.psi.ch/feichtinger
> CH-1211 Genève 23
>
>
>
|