On Wed, 9 Nov 2011 15:36:04 -0600 Steve French <smfrench@xxxxxxxxx> wrote: > On Wed, Nov 9, 2011 at 3:34 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > > On Wed, 9 Nov 2011 15:14:30 -0600 > > Steve French <smfrench@xxxxxxxxx> wrote: > > > > > Part of the issue is whether we view this as a server "bug" or not. > > > Reading the documentation it looks to me like a server bug if > > > it doesn't handle writes up to almost 128K when the flag is on > > > (even though Windows client doesn't us send requests for over 64K, > > > or at least rarely sends over 64K). I don't remember seeing problems > > > with this to any Windows servers, but clearly if more than one > > > major server (NetApp or EMC etc., not just Solaris) had this problem, > > > your argument makes sense. If this is just a bug in a single server > > > implementation, then detecting that and working around it probably > > > makes more sense than punishing NetApp, EMC and Windows > > > for another vendors bug. Do we have data on problems to > > > any other servers with large writes? > > > > > > > I'm not sure and that's a problem. For every user like Nick that takes > > the time to report these sorts of issues, we may have dozens that > > just give up and walk away when they hit them. > > > > > Perhaps - but I think we would have hit these with fsx or connectathon test > suite at the last (SNIA) test event if it were widespread. > Again, we don't know. This is 100% dependent on what the server supports. There is no way to test every possible cifs server that's in the field. All we can do is follow the spec when there is one. When the spec is unclear (as it is in this situation), then we really have little choice but to look to the reference implementation for guidance (aka Windows). -- Jeff Layton <jlayton@xxxxxxxxxx> -- 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
