linux-kernel - Re: CIFS is slooow, gvfs is fast

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 22 Oct 2010 11:06:31 -0500
From:	Steve French <smfrench@...il.com>
To:	Suresh Jayaraman <sjayaraman@...e.de>
Cc:	jamagallon@....com, Linux Kernel <linux-kernel@...r.kernel.org>,
	linux-cifs <linux-cifs@...r.kernel.org>
Subject: Re: CIFS is slooow, gvfs is fast

On Fri, Oct 22, 2010 at 5:44 AM, Suresh Jayaraman <sjayaraman@...e.de> wrote:
>
> (Cc linux-cifs@...r.kernel.org)
>
> On 10/22/2010 05:05 AM, J.A. Magallón wrote:
> > Problem: speed is _VERY_ different.
> > R/W through the automount point (CIFS fs), is roughly 7-8 MB/s (ridiculous
> > for gigabit speeds).
> > R/W through Gnome/gvfs (kind of fuse) goes around 35 - 40 MB/s (400 Mbits/s),
> > that look much better.
>
> What is the kernel version In which you are seeing the problem? I'm not
> seeing this on 2.6.36-rc4. Do you have a wired interface as well? Are
> you sure that both are using the same network path?
>
> > I have tried with different rsize/wsize in mount, but speed is the same
> > (perhaps I did not get the right values...).
>

Read sizes for cifs are relatively small at 16K (unless you change the
maximum buffer sizes at insmod time), and cifs write size is 56K.
This relatively smaller read size and the serializing of relatively
small reads in cifs_readpages can cause slower speeds than you might
expect reading files over gigabit if only one process is using the
network especially if long network latency (lots of dead time on the
network leading to low network utilizations).   cifs will perform
relatively well compared to other options as the number of processes
accessing the network increases, because a lot of work has gone into
locking.  dbench results will often show 50 simultaneous requests to
each Samba server (50 is the traditional maximum number of
simultaneous requests that smb/cifs servers support).   For workloads
other than sequential read workloads - cifs does relatively better as
well.

In the future with smb2 the maximum number of requests can vary, and
the maximum read size is larger which helps, as does the parallelized
smb2 write code which Pavel wrote over the summer for Google Summer of
Code.

--
Thanks,

Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/