On Thu, 7 Feb 2013 13:37:00 +0000 Tom Talpey <ttalpey@xxxxxxxxxxxxx> wrote: > > -----Original Message----- > > From: Jeff Layton [mailto:jlayton@xxxxxxxxxx] > > Sent: Thursday, February 7, 2013 6:50 AM > > To: Suresh Jayaraman > > Cc: Tom Talpey; linux-cifs > > Subject: Re: Writes greater than 64k fails with -ENOSPC > > > > On Thu, 07 Feb 2013 14:22:04 +0530 > > Suresh Jayaraman <sjayaraman@xxxxxxxx> wrote: > > > > > On 01/31/2013 04:54 PM, Jeff Layton wrote: > > > > On Thu, 31 Jan 2013 15:22:15 +0530 > > > > Suresh Jayaraman <sjayaraman@xxxxxxxx> wrote: > > > > > > > >> On 01/30/2013 09:36 PM, Tom Talpey wrote: > > > >>>> -----Original Message----- > > > >>>> From: Jeff Layton [mailto:jlayton@xxxxxxxxxx] > > > >>>> Sent: Wednesday, January 30, 2013 9:37 AM > > > >>>> To: Tom Talpey > > > >>>> Cc: Suresh Jayaraman; linux-cifs > > > >>>> Subject: Re: Writes greater than 64k fails with -ENOSPC > > > >> > > > >>>> > > > >>>> The spec is not 100% clear on whether servers are *required* to > > > >>>> support arbitrarily large writes up to the 128k limit. Clearly > > > >>>> there are some that do not, and a larger default is problematic against > > those servers. > > > >>> > > > >>> I'd be very interested to see traces of negotiate, large read and large > > write from such a server. > > > >> > > > >> I'm not sure whether I can share the complete trace (without > > > >> customer's > > > >> permission) but I can get you the specific bits that might be > > > >> interesting. I have asked for a full trace (including negotiate protocol). > > > >> > > > >> > > > >> Thanks > > > >> > > > >> > > > > > > > > We probably don't need the whole capture. Just the "Capabilities" > > > > and "MaxBufferSize" values from the NEGOTIATE would be enough... > > > > > > > > > > The commit ce91acb3acae26f4163c5a6f1f695d1a1e8d9009 did fix the > > problem. > > > > > > Finally, got the packet capture too. From the NEGOTIATE response, the > > > MaxBufferSize was 65280 and CAP_LARGE_WRITEX (and LARGE_READX) > > had been set. > > > > > > The complete Capabilities were > > > > > > .... .... .... .... .... .... .... ...0 = Raw Mode: Read Raw and Write > > > Raw are not supported .... .... .... .... .... .... .... ..0. = MPX > > > Mode: Read Mpx and Write Mpx are not supported .... .... .... .... > > > .... .... .... .1.. = Unicode: Unicode strings are supported .... .... > > > .... .... .... .... .... 1... = Large Files: Large files are supported > > > .... .... .... .... .... .... ...1 .... = NT SMBs: NT SMBs are > > > supported .... .... .... .... .... .... ..1. .... = RPC Remote APIs: > > > RPC remote APIs are supported .... .... .... .... .... .... .1.. .... > > > = NT Status Codes: NT status codes are supported .... .... .... .... > > > .... .... 1... .... = Level 2 Oplocks: Level 2 oplocks are supported > > > .... .... .... .... .... ...0 .... .... = Lock and Read: Lock and Read > > > is not supported .... .... .... .... .... ..1. .... .... = NT Find: NT > > > Find is supported .... .... .... .... ...1 .... .... .... = Dfs: Dfs > > > is supported .... .... .... .... ..1. .... .... .... = Infolevel > > > Passthru: NT information level request passthrough is supported .... > > > .... .... .... .1.. .... .... .... = Large ReadX: Large Read andX is > > > supported .... .... .... .... 1... .... .... .... = Large WriteX: > > > Large Write andX is supported .... .... .... ...0 .... .... .... .... > > > = LWIO: LWIO ioctl/fsctl is not supported .... .... 0... .... .... > > > .... .... .... = UNIX: UNIX extensions are not supported .... ..0. > > > .... .... .... .... .... .... = Compressed Data: Compressed data > > > transfer is not supported ..0. .... .... .... .... .... .... .... = > > > Dynamic Reauth: Dynamic Reauth is not supported 0... .... .... .... > > > .... .... .... .... = Extended Security: Extended security exchanges > > > are not supported > > > > > > > > > I'm not sure whether restricting it to MaxBufferSize even in case > > CAP_LARGE_WRITEX was set would make sense.. > > > > > > > No, I think that server just happens to have an unusually large > > MaxBufferSize. Most servers send values that are smaller than that. The > > whole idea behind CAP_LARGE_WRITEX is that it allows you to send a write > > that's larger than the MaxBufferSize. > > I agree, but it's still unhelpful that this server accepts only 64KB in response to the client's 124KB large write. In my opinion the server should not be offering CAP_LARGE_WRITEX, although it's certainly legal for it to do so. Perhaps your client should be ignoring it, when MaxBufferSize permits >64KB. > Right. That was the crux of my question a few months ago -- the spec doesn't say how much larger than the MaxBufferSize a server is required to support. In practice, it seems a lot of server vendors didn't do any more than they perceived they had to. > BTW, we're investigating the large write size behaviors for a related MS-SMB doc bug. I don't have the full picture yet, but it appears that Windows SMB servers will process somewhere between 124KB and 128KB-1 bytes when issued a large WRITE_ANDX in this situation. > > Tom. > It's been a while since I wrote this code, but I originally did quite a bit of testing vs. windows versions that were current at the time (win2k8?). At that time, I never saw windows return a short write, but we would generally issue writes that were no larger than 124k or so. We generally use a max of 2^17-1, minus the length of the WRITE_ANDX header (which is small), and then squeeze as many pages as we can fit within it. -- 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
