 |
 |
Hi Andy, thanks for the update. I seems generalized support for opaque data as you proposed in a later mail (I read in reverse order) is the most flexible way (especially since probably not only /alice wants to use this feature). Cheers, Fons. Andy Hanushevsky wrote: > 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 >> -- 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