On Thu, Nov 24, 2011 at 6:20 AM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > On Wed, 23 Nov 2011 23:26:08 -0600 > Steve French <smfrench@xxxxxxxxx> wrote: > >> We are waiting a dochelp response from ms. In addition more data on the >> perf penalty of cutting the wsize in half would help. In any case thecmore >> serious problem is ignoring the write error not the wsize default > > We know there'll be a perf penalty, and I've done some rough numbers > that show about a 30% decrease in some tests. The question is -- is it > a good idea to default to mount options that give better performance > at the expense of interoperability? My vote is no -- the defaults It depends ... one of the less common servers has a bug (which apparently is being fixed) and it apparently hurts write performance significantly to special case the wsize for this one server. Implied in your answer is a worry that other servers incorrectly handle the large write size but as we have seen there is a precedent for writes over 64K (although apparently Windows clients do not send them often - we will know more when Microsoft responds). I am more open to dropping the wsize to the value that fixes the problem to Solaris (100K apparently) and has the least performance penalty unless we get information back from Microsoft indicating a more serious issue. In any case there is no interoperability issue if we handle the error on write (although the code path is tricky, it is a fairly obvious example of "server tells us, late, that it doesn't support this" and if it were codeable to fall back wsize after the write error, there would be no issue to solaris). This is a bad week to get response from Microsoft - but assuming they respond the following week we should have plenty of time to determine if we need to drop the wsize - but I feel uncomfortable ignoring the retry on fairly obvious write error (even though the code path is hard) because that can cause loss of data. -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
