Can you experiment a little with setting different wsize values and see if the server's bug starts at exactly 64K, or as we saw with another server ~100K. There is significant performance benefit in setting the wsize to larger than 64K, but if we find a second server that maxes at ~100K we may want to set it to that. I still would prefer to workaround buggy servers if it were possible to recognize them because I hate to punish (with 20%+ or more worse write performance) the vast majority of servers (Windows,Samba, NetApp) for the bug of a few. Obviously if the problem with the server can not be recognized then we may have to reset wsize - I still would generally prefer (at least for the Solaris case where the server does report an error) to handle the write error and alter the write size for subsequent writes - but as Jeff noted in earlier discussion, although possible, it is a harder patch to do. I would be curious though if your server gives any indication of write error or silently ignores the large write. On Sat, Jan 14, 2012 at 8:33 AM, Jeff Layton <jlayton@xxxxxxxxx> wrote: > On Sat, 14 Jan 2012 14:50:58 +0100 > Mirko Scholz <mscholz5@xxxxxxx> wrote: > >> >> > Does the problem go away if you mount with wsize=65535? If so, I guess we >> > can add bluearc to the list of servers that can't handle writes larger than >> > windows sends. >> yes it does. Thanks for pointing it out, as it is clearly mentioned >> in mount.cifs(8). But it says, that this size is negotiated...? >> > > To a degree... > > We attempt to set the wsize according to what the server supports, but > there is no way for the server to say "I only support writes up to this > size". Currently, when the server says it supports large writes, we > attempt to set the wsize as large as we can go -- ~127k or so. > > Windows servers support that just fine, but windows clients never send > writes larger thank 64k. Unfortunately, some servers are not engineered > to handle larger writes, and only handle up to what windows clients > default to. > > I sent a patch a while back to set the default wsize to match what > windows does, but Steve has so far refused to take it. > >> > Steve is right though that a capture would be helpful to confirm what's >> > happening. >> >> You'll find it at http://www.gwdg.de/~mscholz5/cifs-problem/v3.1.0-1 >> >> Thank you both for the quick reply. I noticed this problem a while ago, >> but hasitated to report it, since cifs is not officially supported >> at my site. >> >> Steve, do you still need the bug-report? >> > > Thanks -- there's probably no need for a bug report. I think I > understand the problem. You can probably set wsize=65536, actually and > it should still work. > > The server is responding to a 66560 byte write with a length of 65536. > The current code treats a short write like an -ENOSPC error. It's not > ideal, but the spec doesn't really spell out what a short write means, > and it would be quite difficult to try to recover from this situation > gracefully. > > Steve, the list of servers that do not support >64k writes is growing. > Are you ready to take my patch to set the default wsize lower yet? > > -- > Jeff Layton <jlayton@xxxxxxxxx> -- 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
