From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve French Subject: Re: Kernel 3.0: Instant kernel crash when mounting CIFS (also crashes with linux-3.1-rc2 Date: Thu, 18 Aug 2011 11:02:25 -0500 Message-ID: References: <20110815064734.403b630f@corrin.poochiereds.net> <3300.1313637592@jrobl> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: "J. R. Okajima" , Jeff Layton , Jesper Juhl , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Alan Piszcz , Steve French , linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Justin Piszcz Return-path: In-Reply-To: Sender: linux-cifs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: I did some testing with 3.0 kernel (cifs client) and was getting 90% wire speeds writing cifs files to the server (Windows or Samba) On Thu, Aug 18, 2011 at 11:01 AM, Steve French wro= te: > Writing from cifs kernel client to WIndows or Samba server should be = much faster > than the reverse (ie large file sequential file copy to server is > faster than copying > a file from the server) =A0cifs kernel client serializes reads from t= he same file > (unless mounting forcedirectio, in which case caching is disabled) an= d uses > a relatively smaller read size (16K) - while for writes they are sent > in parallel > even if to the same file (and the write size is much larger e.g. 1269= 76 bytes, > and can be set even larger to Samba). =A0There may be a few cases (su= ch > as copying to WIndowsXP or Windows7) where timeouts on the > server slow things down (writing from linux client to Windows XP > or Windows 7) but what is the server type? > > > On Thu, Aug 18, 2011 at 7:14 AM, Justin Piszcz wrote: >> >> >> On Thu, 18 Aug 2011, Justin Piszcz wrote: >> >>> >>> >>> On Thu, 18 Aug 2011, J. R. Okajima wrote: >>> >>>> >>>> Justin Piszcz: >>>>> >>>>> Does anyone know if any kernel supports CIFS w/out crashing? I'd = like to >>>>> backup some CIFS shares, thanks. >>>>> >>>>> >>>>> mount -t cifs //w2/x /mnt -o user=3Duser,pass=3Dpass >>>>> >>>>> [ =A0881.388836] CIFS VFS: cifs_mount failed w/return code =3D -2= 2 >>>> >>>> =A0 =A0 =A0 =A0::: >>>> >>>> Since it failed mounting, this patch will help you. Although the p= atch >>>> will fix one bug, there still may exist another problem. >>>> >>>> http://marc.info/?l=3Dlinux-cifs&m=3D131345112022031&w=3D2 >>> >>> Hi, >>> >>> Latest patch (this one) applied to linux-3.1-rc2 works, at least it >>> mounted >>> this time and did not instantly crash the kernel! >>> >>> I also tried the hostname again (and it did not crash the kernel, b= ut it >>> failed to mount). >>> >>> Used the IP and it mounted successfully: >>> //10.0.0.11/x =A0 =A0 =A0 =A0 =A028T =A05.0T =A0 23T =A019% /mnt >>> //10.0.0.11/y =A0 =A0 =A0 =A0 =A019T =A01.2T =A0 18T =A0 7% /mnt2 >>> >>> It has not crashed yet (which is good), I'll apply this patch to my >>> production machine and test taking backups of this data and let you= know >>> if it crashes again, thanks! >>> >>> Justin. >> >> >> Hello, >> >> It is working but very slowly: >> >> Device eth6 [10.0.1.2] (1/1): >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >> Incoming: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= Outgoing: >> Curr: 37.60 MByte/s =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Curr: 0.= 44 MByte/s >> Avg: 4.98 MByte/s =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Avg: 0= =2E09 MByte/s >> Min: 0.00 MByte/s =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Min: 0= =2E00 MByte/s >> Max: 40.79 MByte/s =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Max: 0= =2E48 MByte/s >> Ttl: 1.45 GByte =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ttl:= 26.77 MByte >> >> Over 10GbE the other direction (Linux -> Windows (via Samba)) I get >> 500MiB/s, is CIFS slow? >> >> I'll look into options to tweak the speed but this is very poor spee= d when >> you have to transfer 5-10TB. =A0However, it is not crashing anymore,= so any >> speed is better than that :) >> >> Justin. >> >> > > > > -- > Thanks, > > Steve > --=20 Thanks, Steve From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756026Ab1HRQC2 (ORCPT ); Thu, 18 Aug 2011 12:02:28 -0400 Received: from mail-qw0-f46.google.com ([209.85.216.46]:54747 "EHLO mail-qw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755332Ab1HRQC0 convert rfc822-to-8bit (ORCPT ); Thu, 18 Aug 2011 12:02:26 -0400 MIME-Version: 1.0 In-Reply-To: References: <20110815064734.403b630f@corrin.poochiereds.net> <3300.1313637592@jrobl> Date: Thu, 18 Aug 2011 11:02:25 -0500 Message-ID: Subject: Re: Kernel 3.0: Instant kernel crash when mounting CIFS (also crashes with linux-3.1-rc2 From: Steve French To: Justin Piszcz Cc: "J. R. Okajima" , Jeff Layton , Jesper Juhl , linux-kernel@vger.kernel.org, Alan Piszcz , Steve French , linux-cifs@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I did some testing with 3.0 kernel (cifs client) and was getting 90% wire speeds writing cifs files to the server (Windows or Samba) On Thu, Aug 18, 2011 at 11:01 AM, Steve French wrote: > Writing from cifs kernel client to WIndows or Samba server should be much faster > than the reverse (ie large file sequential file copy to server is > faster than copying > a file from the server)  cifs kernel client serializes reads from the same file > (unless mounting forcedirectio, in which case caching is disabled) and uses > a relatively smaller read size (16K) - while for writes they are sent > in parallel > even if to the same file (and the write size is much larger e.g. 126976 bytes, > and can be set even larger to Samba).  There may be a few cases (such > as copying to WIndowsXP or Windows7) where timeouts on the > server slow things down (writing from linux client to Windows XP > or Windows 7) but what is the server type? > > > On Thu, Aug 18, 2011 at 7:14 AM, Justin Piszcz wrote: >> >> >> On Thu, 18 Aug 2011, Justin Piszcz wrote: >> >>> >>> >>> On Thu, 18 Aug 2011, J. R. Okajima wrote: >>> >>>> >>>> Justin Piszcz: >>>>> >>>>> Does anyone know if any kernel supports CIFS w/out crashing? I'd like to >>>>> backup some CIFS shares, thanks. >>>>> >>>>> >>>>> mount -t cifs //w2/x /mnt -o user=user,pass=pass >>>>> >>>>> [  881.388836] CIFS VFS: cifs_mount failed w/return code = -22 >>>> >>>>        ::: >>>> >>>> Since it failed mounting, this patch will help you. Although the patch >>>> will fix one bug, there still may exist another problem. >>>> >>>> http://marc.info/?l=linux-cifs&m=131345112022031&w=2 >>> >>> Hi, >>> >>> Latest patch (this one) applied to linux-3.1-rc2 works, at least it >>> mounted >>> this time and did not instantly crash the kernel! >>> >>> I also tried the hostname again (and it did not crash the kernel, but it >>> failed to mount). >>> >>> Used the IP and it mounted successfully: >>> //10.0.0.11/x          28T  5.0T   23T  19% /mnt >>> //10.0.0.11/y          19T  1.2T   18T   7% /mnt2 >>> >>> It has not crashed yet (which is good), I'll apply this patch to my >>> production machine and test taking backups of this data and let you know >>> if it crashes again, thanks! >>> >>> Justin. >> >> >> Hello, >> >> It is working but very slowly: >> >> Device eth6 [10.0.1.2] (1/1): >> ================================================================================ >> Incoming:                               Outgoing: >> Curr: 37.60 MByte/s                     Curr: 0.44 MByte/s >> Avg: 4.98 MByte/s                       Avg: 0.09 MByte/s >> Min: 0.00 MByte/s                       Min: 0.00 MByte/s >> Max: 40.79 MByte/s                      Max: 0.48 MByte/s >> Ttl: 1.45 GByte                         Ttl: 26.77 MByte >> >> Over 10GbE the other direction (Linux -> Windows (via Samba)) I get >> 500MiB/s, is CIFS slow? >> >> I'll look into options to tweak the speed but this is very poor speed when >> you have to transfer 5-10TB.  However, it is not crashing anymore, so any >> speed is better than that :) >> >> Justin. >> >> > > > > -- > Thanks, > > Steve > -- Thanks, Steve