 |
 |
Hi Fons, In retrospect it would seem that the cleanest way of handling "special" filenames is to make them part of the path as one would use an actual filename. So, you would recognize an "alice" name by the path prefix, say '/alice/". Then whatever follows that would be the encoded filepath which the wrapper would decode and replace the path with the decoded name and forwarded into the regular interface. This now seems much cleaner than trying to pass the encoded information via opaque information. Opaque information was originally meant to provide hinst about file placement and usage at open time. When I spoke to Andreas I thought that it could also be used to pass the alice name. What I forgot was that the opaque information is only considered for open calls and simplky passed through (if it exists) for other calls. It is open for discussion in what context opaque information should be passed and what context it should be filtered out (and I'm certainly open to suggestions on how best to treat opaque information in all contexts). So, the bottom line is that the non-uniform treatment of opaque information is casing usage problems when one tries to generalize that to other file methods. Notwithstanding this issue, there is still a bug in how the olbd treats opaque information. This was introduced in the last release by our tring to inform the olbd which servers are causing problems and not fixing the olbd to recognize that such information is being provided. I will be fixing that shortly. This is only an issue when a client is misdirected to a server. Andy ----- Original Message ----- From: "Fons Rademakers" <[log in to unmask]> To: "Andy Hanushevsky" <[log in to unmask]> Cc: "Derek Feichtinger" <[log in to unmask]>; "xrootd mailing list" <[log in to unmask]>; "Andreas Joachim Peters" <[log in to unmask]> Sent: Tuesday, April 26, 2005 2:10 AM Subject: Re: olbd fails to learn when a file disappears from a leaf node, but another copy still exists > 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.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 >>> >>> >>> > > -- > Org: CERN, European Laboratory for Particle Physics. > Mail: 1211 Geneve 23, Switzerland > E-Mail: [log in to unmask] Phone: +41 22 7679248 > WWW: http://www.rademakers.org/fons/ Fax: +41 22 7679480 >