[OpenAFS] Re: No buffer space available

Stephan Wiesand stephan.wiesand@desy.de
Fri, 11 Oct 2013 19:29:40 +0200


On Oct 11, 2013, at 19:01 , Andrew Deason wrote:

> On Fri, 11 Oct 2013 17:36:52 +0200
> Stephan Wiesand <stephan.wiesand@desy.de> wrote:
>=20
>>> I don't see anywhere we'd be generating that error code (ENOBUFS),
>>> and I can't see how it would show up that way if we got it back from
>>> a socket or something. Do you have any idea if the machine is under
>>> a lot of load or memory pressure, or if the directory has a lot of
>>> entries in it?
>=20
> For some reason I never looked at the actual value of this; I thought
> ENOBUFS was some low-numbered errno for some reason. But it appears to
> be 105, which is VNOSERVICE, which means this is probably due to
> idle-dead brokenness.
>=20
> Speaking to you in the context of 1.6 maintenance: this isn't really =
new
> (though this specific manifestation might be, I'm not sure). Gerrit =
8462
> would help with it, and could possibly go into 1.6.6 if we want to do
> something about it. Actually fixing it was discussed in 8464; I just
> need to get around to actually implementing it sometime (none of the
> submitted patches in there are correct; a different solution is
> discussed somewhere in there).=20
>=20
>> To add a data point:
>>=20
>> I just encountered this while copying two rather small files for the
>> 1.6.5.1 release from here (~ Berlin) to PENN-CENTRAL.SRV.CS.CMU.EDU.
>=20
> I assume this was hanging for a little while before erroring out, yes?

Sorry, I really can't tell. When you copy files around a quarter of the =
globe, there are always delays. And as usual, I fired the command and =
then went on to something else. I'm fairly sure it didn't hang for more =
than about a minute though.

--=20
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany