On Sat, Jan 14, 2012 at 03:46:05PM -0600, Steve French wrote: > 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. Wouldn't the -ENOSPC not appear at that size? Anyways I tried 68k, 80k and 100k, the problem of truncation remains. > 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. IMHO there are a couple of alternatives, that do not punish other servers: educate your users, as * while elevated logging display a warning when encountering a short write. Just that someone without deeper CIFS knowledge gets a hint. I just didn't follow linux-cifs and haven't been aware of the wsize option at all, sorry. or do the workaround * during negotiation log something like "detected buggy/sub-performant server, setting wsize to known safe 65536" as at least one NIC driver did * go with 64k as default and have a white list of performant servers Whether you black or white list depends entirely which list is expected to be more definitive, doesn't it? As I have no clue how many different CIFS servers there are, the white list sounds more rational to me. But our setup may be a bit special anyways because Blue Arc supports NFS exports. IT dept. only objects against shared access. > I would be curious though if your server gives any indication of write > error or silently ignores the large write. Expect an answer during next week. I myself cannot obtain such information. Mirko -- 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
