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
|