 |
 |
Hi, Fons Here, opaque information is additional information that can be transmitted in a request by adding it after a separation tag (&) to the file's URL (quite like in a http GET). To implement the authorization scheme we came up with, Andreas used this opaque information to transfer the token together with the filename. The current bug affects the resilience of xrootd when it sits on disks that are managed by some external means. Our authorization method can be reimplemented in another way, as Andy suggests. Cheers, Derek On Tuesday 26 April 2005 11.10, Fons Rademakers wrote: > Hi Andy, > > can you update me on this issue. What are opaque file names? ALICE has > not yet finalized any file name structure so we are flexible and would > prefer the best technical solution. > > Cheers, Fons. > > Andy Hanushevsky wrote: > > 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.2 > >>00504/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 -- 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