 |
 |
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. Fabrizio 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 >>request. >>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? >> >>Fabrizio >> >>