On Fri, 8 Oct 2010 17:43:44 -0400 Simon Wilkinson <s...@inf.ed.ac.uk> wrote:
> On 8 Oct 2010, at 17:24, Andrew Deason wrote: > > > This is probably the throttling behavior of the fileserver, where > > the fileserver throttles client activity if it sends too many RPCs > > that return error codes in a certain amount of time. Actually, this is a per-connection (and per-call) count, IIRC; it's not within a certain amount of time and it never goes down unless you get a new conn. > I do wonder if the abort threshold is too aggressive when applied to > authenticated clients. Whilst a denial of service attack is possible > from authenticated clients, it's also more likely that there will be > administrative means available to track down and punish offenders. Yeah, I agree with the general idea. I'm not sure if just increasing the threshold is good enough, since once you hit it the performance just goes straight to N req/s (right now N=1, I think) effectively forever as long as you're constantly using the conn. Maybe we should also change the throttled rate, or just reset the count after a certain amount of time (which would effectively do the same thing amortized). Although, just a separate thresh is a lot easier, and being able to configure '-aborttreshold 0' just for auth'd conns would be nice. > Maybe we need two different thresholds depending on the class of the > client. Or maybe N thresholds, for any of the existing or future security class indices? (This sounds annoying to tweak via command line arguments; when are we getting a config file again? ;) -- Andrew Deason adea...@sinenomine.net _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
