On Thu, 07 Feb 2013 14:22:04 +0530 Suresh Jayaraman <[email protected]> wrote:
> On 01/31/2013 04:54 PM, Jeff Layton wrote: > > On Thu, 31 Jan 2013 15:22:15 +0530 > > Suresh Jayaraman <[email protected]> wrote: > > > >> On 01/30/2013 09:36 PM, Tom Talpey wrote: > >>>> -----Original Message----- > >>>> From: Jeff Layton [mailto:[email protected]] > >>>> 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. -- Jeff Layton <[email protected]> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
