On Fri, 11 Oct 2013 17:36:52 +0200 Stephan Wiesand <[email protected]> wrote:
> > 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? 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. 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). > To add a data point: > > 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. I assume this was hanging for a little while before erroring out, yes? -- Andrew Deason [email protected] _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
