XROOTD-L Archives

Support use of xrootd by HEP experiments


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Fabrizio Furano <[log in to unmask]>
13 Oct 2005 10:05:27 +0200Thu, 13 Oct 2005 10:05:27 +0200
text/plain (50 lines)
Hi Andy,

  I quite understand, but this is a little cryptic to me.
  The thing that I dislike in line of principle is that a server side 
resource related trouble is treated by the whole system as a deadly 
situation. And the result is a truncated file copy, which is really bad.

  I wonder if the garble can be solved by making the client treat that 
kind of error as a recoverable one instead of a fatal one. If you think 
that this policy won't make bad things worse, I'll have a look into it.


Andrew Hanushevsky wrote:
> Hi Fabrizio,
> I looked into this some more. Apparently, it is not a kernel issue. What
> xrootd is complaining about is that it should have had an available buffer
> to do the I/O request but there was not one to be found. I'm not sure what
> this indicates exactly since it's one of those conditions that should
> never happen. As xrootd found itself in an untenable situation it threw
> up it's hands and terminated your request.
> Andy
> On Wed, 12 Oct 2005, Fabrizio Furano wrote:
>>Hi Andy,
>> copying files with xrdcp I got this error from the kan cluster:
>>051012 09:04:16 14869 Xrd: ReadBuffer: Server
>>[kan007.slac.stanford.edu:1094] did not return OK message for last
>>051012 09:04:16 14869 Xrd: SendGenCommand: Server declared error
>>3008:XrdXrootdAio: Unable to
>>read /store/PRskims/R14/14.4.2a/BToDlnu/04/BToDlnu_0416.03HUBCA.root; No
>>buffer space available
>> To me it sounds ugly. It happened approaching the end of this copy. What do you think?