Subject: Re: CIFS slowness & crashes - msg#00011

List: linux.file-systems.cifs

Date: Prev Next Index Thread: Prev Next Index

On Thu, 2005-07-21 at 17:04, Jesper Juhl wrote:
> On 7/21/05, Lasse Kärkkäinen / Tronic <tronic+lzID=lx43caky45@xxxxxxxxxx>
> wrote:
> > I mailed sfrench@xxxxxxxxx (the guy who wrote the driver) about this a
> > month ago, but didn't get any reply. Is anyone working on that driver
> > anymore?
> >
> As far as I know Steve is still maintaining cifs. If you wrote him and
> didn't get a response, then try again after a while (you might have
> included him on CC for this mail) - maintainers don't always have time
> to answer all mail in a timely fashion (or at all), and it's your
> responsability to resend - that's not news.

CIFS is still being actively improved/maintained. I was out on vacation
for over a week. It might have gotten missed in the flood of email I
had to catch up on. I am still maintaining cifs and evaluating patches
from others as well. As you can see from the web git page, changesets
are still being added. You can see the list of CIFS changesets (most
recent first) by the query:

http://www.kernel.org/git/?p=linux%2Fkernel%2Fgit%2Fsfrench%2Fcifs-2.6.git&a=search&s=CIFS

> You could also have written to the samba-technical@xxxxxxxxxxxxxxx
> mailinglist (or copied it - it's listed in MAINTAINERS under "COMMON
> INTERNET FILE SYSTEM (CIFS)").
>
> [adding Stephen French to CC]
>
> Personally I'd probably have send the mail
> To: Steve French <sfrench@xxxxxxxxx>
> Cc: samba-technical@xxxxxxxxxxxxxxx
> Cc: linux-kernel@xxxxxxxxxxxxxxx

Yes. CCing those lists is recommended. The best list to send to is and
which I and others in this area monitor regularly though is
linux-cifs-client@xxxxxxxxxxxxxxx

> > not possible to umount with either smbumount (hangs)
smbumount can not be called on cifs vfs mounts (it is for the older
smbfs). Although there is a somewhat similar umount.cifs utility
(umount.cifs.c in the samba 3 source) it will be obsolete when
more general user umounting (of their own mounts) is permitted
in the kernel vfs itself.

> nor umount -f
> > (prints errors but doesn't umount anything).

What are the errors? What is the version of cifs.ko module?

> It won't recover without
> > reboot, even if the server becomes back online.
> >
> > This problem has been around as long as I have used SMBFS or CIFS. There
> > has only been slight variation from one version to another. Sometimes it
> > is possible to umount them (after some pretty long timeout), sometimes
> > it is not. It seems as if the problem was being fixed, but none of the
> > fixes really worked.

My tests of reconnection after server crash or network reconnection with
smbfs works (for the past year or two) and also of course for cifs.
cifs also reconnects state (open files) not just the connection to
\\server\share

> >
> > 2. Occassionally the transmission speeds go extremely low for no
> > apparent reason. While writing this, I am getting 0.39 Mo/s over a
> > gigabit network.

My informal tests (cifs->samba) showed a maximum of about 20%
utilization of gigabit doing large file writes and about double that for
large file reads with a single cifs client to Samba over gigabit. Should
be somewhat simalar to Windows server.

The most common cause of widely varying speeds are the following:
1) memory fragmentation - some versions of the kernel badly fragment
slab allocations greater than 4 pages (cifs by default allocates 16.5K
buffers - which results in larger size allocations when more than 5
processes are accessing the mount and the cifs buffer pool is exceeded)
2) write behind due to oplock - smbfs does not do oplock, cifs does -
which means that cifs client caching can cause a large amount of
writebehind data to accumulate (with great performance for a while) -
then when memory gets tight due to the inode caching in linux's mm
layer, the cifs client is asked to write out a large amount of file data
at one time (which it does synchronously).

Both of these are being improved. You can bypass the inode caching on
the client by using the cifs mount option
"forcedirectio"

> Using FTP to read the same file gives 40 Mo/s,
Similarly NFS was somewhat better than that (as long as the file was in
memory already on the server).

Was this page helpful?

Thread at a glance:

Previous Message by Date: click to view message preview

RE: Find_First with InfoLevel 0x104(260) doesn't

True. The code is there, but is not being used right now. But incidentally I found that the structure in SNIA spec does say it is a WCHAR, and the structure in cifspdu.h has a u8, so I tried. Naidu Bollineni Senior Member Technical Staff Kazeon Systems naidu@xxxxxxxxxx www.kazeon.com From: Steven French [mailto:sfrench@xxxxxxxxxx] Sent: Wednesday, July 20, 2005 1:56 PM To: Naidu Bollineni Cc: linux-cifs-client@xxxxxxxxxxxxxxx Subject: RE: [linux-cifs-client] Find_First with InfoLevel 0x104(260) doesn't > For me it did not because the structure FILE_BOTH_DIRECTORY_INFO has member Shortname declared __u8 inctead of __u16. I don't see the readdir code using that level (0x104), just SMB_FIND_FILE_DIRECTORY_INFO (0x101) and SMB_FIND_FILE_FULL_DIRECTORY_INFO (0x102) as well as the Unix extensions find level, so shortname should not be an issue there (it is not returned by 101 and 102 and the cifs client does not need it). If shortname length were not calculated correctly and level 104 were ever issued, readdir should fail horribly since filename would be wrong. Steve French Senior Software Engineer Linux Technology Center - IBM Austin phone: 512-838-2294 email: sfrench at-sign us dot ibm dot com _______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client

Next Message by Date: click to view message preview

[Fwd: Re: CIFS slowness & crashes]

forgot to CC the list --- Begin Message --- > > 2. Occassionally the transmission speeds go extremely low for no > > apparent reason. While writing this, I am getting 0.39 Mo/s over a > > gigabit network. It would help to know whether you are doing mostly writing to or reading from the server. Forgot to mention that another thing that may help (besides the large number of improvements that already went into 2.6.12 already to drastically reduce the expensive large buffer usage, and the even newer experimental CIFS write code) are two configuration changes - either dropping the buffer size to relieve pressure on the slab (e.g. to just under 8K - perhaps 7800 bytes) or increasing the number of large buffers in the pool (they are insmod parms of cifs.ko - you can do modinfo on cifs.ko to see them) so fewer allocations are done. This would only be needed if multiple processes were accessing the mount at one time. --- End Message --- _______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client

Previous Message by Thread: click to view message preview

RE: Find_First with InfoLevel 0x104(260) doesn't

I am wondering if an attempt to use Infolevel 0x104 on FirstFirst is showing correct output. For me it did not because the structure FILE_BOTH_DIRECTORY_INFO has member Shortname declared __u8 inctead of __u16. Changing it to __u16 is showing correct result, and ethereal trace does confirm there are 24 bytes before the real Unicode FileName of the entry. Naidu Bollineni Senior Member Technical Staff Kazeon Systems naidu@xxxxxxxxxx www.kazeon.com From: linux-cifs-client-bounces+naidu=kazeon.com@xxxxxxxxxxxxxxx [mailto:linux-cifs-client-bounces+naidu=kazeon.com@xxxxxxxxxxxxxxx] On Behalf Of Steven French Sent: Wednesday, July 20, 2005 9:47 AM To: dean.davis@xxxxxxxxxxx Cc: linux-cifs-client@xxxxxxxxxxxxxxx Subject: Re: [linux-cifs-client] Slow Samba Share access to CIFS-mount - Win2k3Share Your post did not included enough information to be conclusive about the cause of the performance change after update of the server side to newer Windows server version, but there are a couple things that could be done to isolate it. I like to use more granular performance tools (iozone e.g., or the connectathon "nfs" tests run in timing "-t" mode) to compare before and after - and then compare with the network traces to see whether any particular type of request is slower after the change. As a long shot (in the dark) .... A new performance consideration which I had not noticed before is TCP ack timeouts - depending on the size of the tcp window and various issues relating to TCP's "nagle" algorithm, TCP acks can be delayed to allow acks to be sent with subsequent requests or responses. This can be a disaster for performance of one process on one client talking to one server over very high speed links since it results in much dead time on the wire in which neither end is doing anything. Tuning around this (e.g. changing the sizes of the request buffer via insmod or on the server side) is a possibility and in any case is easy enough to do that it is worth trying. I am looking at how to disable the nagle algorithm code on the socket on the client as well. This may have nothing to do with it, but I stumbled across it when I saw that a performance improvement I had made in some cases made things an order of magnitude slower when larger responses were sent. Steve French Senior Software Engineer Linux Technology Center - IBM Austin phone: 512-838-2294 email: sfrench at-sign us dot ibm dot com _______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client

Next Message by Thread: click to view message preview

Re: CIFS slowness & crashes

On 21 Jul 2005 17:35:12 -0500, Steve French <smfltc@xxxxxxxxxx> wrote: > Yes. CCing those lists is recommended. The best list to send to is and > which I and others in this area monitor regularly though is > linux-cifs-client@xxxxxxxxxxxxxxx If that's the best list to send to, then I suggest it be added to the CIFS MAINTAINERS entry as pr the patch below (also attached since gmail will probably mangle it). Add linux-cifs-client@xxxxxxxxxxxxxxx to CIFS entry in MAINTAINERS Signed-off-by: Jesper Juhl <jesper.juhl@xxxxxxxxx> --- MAINTAINERS | 1 + 1 files changed, 1 insertion(+) --- linux-2.6.13-rc3-orig/MAINTAINERS 2005-07-14 20:33:32.000000000 +0200 +++ linux-2.6.13-rc3/MAINTAINERS 2005-07-22 01:42:09.000000000 +0200 @@ -532,6 +532,7 @@ COMMON INTERNET FILE SYSTEM (CIFS) P: Steve French M: sfrench@xxxxxxxxx +L: linux-cifs-client@xxxxxxxxxxxxxxx L: samba-technical@xxxxxxxxxxxxxxx W: http://us1.samba.org/samba/Linux_CIFS_client.html S: Supported -- Jesper Juhl <jesper.juhl@xxxxxxxxx> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html CIFS_add_linux-cifs-client_list_to_MAINTAINERS.patch Description: Text Data _______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client

Loading Comments...