Date: Sun, 21 Feb 1999 02:53:10 -0600 (CST) From: Kevin Day <toasty@home.dragondata.com> To: dillon@apollo.backplane.com (Matthew Dillon) Cc: hackers@FreeBSD.ORG Subject: Re: ESTALE the best approach? Message-ID: <199902210853.CAA25778@home.dragondata.com> In-Reply-To: <199902210842.AAA18826@apollo.backplane.com> from Matthew Dillon at "Feb 21, 1999 0:42:51 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> : > :Anyone have any comments on this? > > Only cron is maintained here. All the other programs are maintained > by their authors or groups elsewhere. There isn't much we can do about > them. > > Also, most of these are IRC tools. IRC tools are notoriously badly > written. To give you an example, there was an eggdrop floating around > for months about a year ago which had hacked in signal(SIGSEGV, handler) > to make the program ignore segv violations because the programmer who > made the mod was too clueless to understand what sigsegv actually meant. Most of my customers are running irc tools, so that's probably why i'm mostly finding irc tools causing the problems. I'll probably end up patching something locally to just shoot the program down if it would have ESTALE'ed, since my chances of getting ~1000 people to patch their software is pretty well 0. Having a confused piece of software saturate a 100MB ethernet link with nfs getattr requests, and knock the load up on both the nfs client and server is definately a bad thing. Setting a cpu limit on for the client doesn't work either. Most of the time spent doing this isn't accounted to the buggy program, and, when a process gets killed for 'cpu time exceeded', and the executable is ran from an nfs mount, hell tends to break loose. (vm_fault: pager input (probably hardware error) messages begin to flood you to death) But... Does anyone really take ESTALE and do anything productive with it? I can't really think of many situations where you're going to do anything but abort after seeing this. At least... Nothing I'm running needs to know about it. :) Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902210853.CAA25778>