From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Steve French" Subject: Re: Large SMBwriteX testing. Date: Wed, 7 Nov 2007 16:56:32 -0600 Message-ID: <524f69650711071456l59186c44na837df5dbe340920@mail.gmail.com> References: <524f69650711011216s17cbc26ra337d70a0bde8d03@mail.gmail.com> <20071103004312.GA1204@samba1> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: samba-technical@lists.samba.org, linux-cifs-client@lists.samba.org, "Amit K. Arora" , linux-fsdevel To: "Jeremy Allison" Return-path: Received: from py-out-1112.google.com ([64.233.166.180]:7387 "EHLO py-out-1112.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755227AbXKGW4d (ORCPT ); Wed, 7 Nov 2007 17:56:33 -0500 Received: by py-out-1112.google.com with SMTP id u77so4712049pyb for ; Wed, 07 Nov 2007 14:56:32 -0800 (PST) In-Reply-To: <20071103004312.GA1204@samba1> Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org I have verified that it works for the case in which "min receivefile size" is under 128K. When I set it to 250000 and tried to read 148000 there were two or three problems (reply_write_and_X in Samba is calling smb_len instead of smb_len_large and it is looking for "req->unread_bytes" incorrectly in a few places in reply.c and fileio.c On Nov 2, 2007 6:43 PM, Jeremy Allison wrote: > Hi Steve, > > I've finished adding the ability for smbd to support up to > 16MB writeX calls in the latest git 3.2 tree. > > To enable, set the parameter : > > min receivefile size = XXX > > where XXX is the smallest writeX you want to handle with recvfile. > > The linux kernel doesn't yet support zerocopy from network to > file (ie. splice only works one way currently) so it's emulated > in userspace (with a 128k staging buffer) for now. > > Also it must be an unsigned connection (for obvious reasons). > > Once you've set this param smbd will start reporting > CIFS_UNIX_LARGE_WRITE_CAP on a SMB_QUERY_CIFS_UNIX_INFO: > call and you should be good to go. You'll need to use > a writeX call identical to Windows (14 wct with a 1 byte > pad field) in order to trigger the new code. > > Let me know if you get the chance to test it and if > it makes a speed difference for CIFSFS. > > Cheers, > > Jeremy. > -- Thanks, Steve