Hi Yi, I believe I have already given a couple of good reasons why as many parameters as possible should be tunable. And I also think that the approach to ask for a detailed explanation and use case for each and every parameter is not the right approach to the problem. So far I have only asked to implement the easiest possible solution (suggesting to implement per-session/connection/target tunables later), so the effort to implement these changes should be minimal and I would expect zero maintenance effort - plus a couple more happy customers.
I will summarize again my key arguments: * There is no strong reasoning behind the chosen parameters, the now hardcoded values are relatively arbitrary. We need experience from the field to let evolve the values appropriate for most environments and we will most probably need to work on recommendations for various environments (e.g. we already have two cases: Optimizing for a fast failure vs. for a maximally robust connection). In short: We know of at least two cases where the current parameters dont match. * In real world scenarios, customers will find themselves in situations where they would need to tune a parameter "now" to work around bugs or other issues, to stabilize an unstable system etc. etc. If we only have compile time values, there is absolutely no way out of such situations and I guarantee that customers *will* complain to support about this. In short: We need flexibility. * It does not harm to make #defines kernel tunables I do second the argument that before implementing per session/connection/target tunables (with iscsiadm commands to control them), we need to be sure that there is a valid demand, but on the other hand I must say that so far I have not heard one sound argument why not to make these compile time defaults kernel tunables in the first step. If you insist, I will try to find scenarios where tuning each and every parameter, but you will probably know that it is very hard to foresee use cases and failure scenarios - so whatever we come up with now will most likely be incomplete. And, again, I do think that my arguments are very valid already. Community? And other opinions? Nils _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
