On 1/26/2012 1:03 PM, Andrew Deason wrote: > I saw some emails to you today that sounded like someone wanted it :) > > But sure, some people may want something like that. Some people want > hardmount. (Not saying we need an option for that at this time or > anything, though.)
That is certainly one interpretation. The other is that they want the root cause of the data corruption problems to be fixed. >>> I believe/assume what is being considered "right" is the latter >>> option. >> >> ? > > I definitely heard some advocacy for this the last time we were arguing > about this (how the fileserver-side should make this determination, > which is true, but...). But yeah, this isn't what went in. The file server now disable keep alives when performing disk I/O. If the I/O doesn't return, the clients will timeout. This is in tree. > Well, I was talking about idledead stuff here, specifically client > behavior, which isn't going to screw up another client. I think that > matters much more when you're talking about server behavior, in which > case, yes, certainly. Clients that use idle-dead timeouts to cancel and retry RPCs do have negative impacts on other clients. Repeated retries of RPCs that the file server cannot process because a vnode is already locked result in the thread pool becoming depleted. The side effect is that a file server will enter a state where it can process no requests much sooner than it otherwise would have.
signature.asc
Description: OpenPGP digital signature
