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