 |
 |
Hi all, I am not sure I know all the details of the discussion, but I think that xrootd should be treated like a "normal" file server in any place we can. So, in my opinion the more elegant solution is the note on the b), eventually writing an alice-friendly sfs which does the correct mapping and lookup. I fear that putting too many hacks around would make even normal things harder than they are. Fabrizio On Tuesday 26 April 2005 04:19 am, 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.20 > >0504/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 -- -------- Fabrizio Furano INFN - Istituto Nazionale di Fisica Nucleare [log in to unmask]