[Previous Thread]  

[linux-cifs] Re: [PATCH] cifs: handle cifs_get_tcon() errors properly


  • Subject: Re: [PATCH] cifs: handle cifs_get_tcon() errors properly
  • From:    Suresh Jayaraman <sjayaraman-l3A5Bk7waGM <at> public.gmane.org>
  • To:      Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA <at> public.gmane.org>
  • Cc:      Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w <at> public.gmane.org>, linux-cifs-u79uwXL29TY76Z2rM5mHXA <at> public.gmane.org
  • Date:    2010-11-15 14:54:41
On 11/15/2010 06:55 PM, Jeff Layton wrote:
> On Mon, 15 Nov 2010 18:15:23 +0530
> Suresh Jayaraman  wrote:
> 
>> cifs_get_tcon() could return any of the following errors:
>> -ENOMEM/-ENODEV/EREMOTEIO. We should follow the DFS referral code path only
>> when we get -EREMOTEIO (STATUS_PATH_NOT_COVERED) from the server and not
>> otherwise.
>>
>> Compile-tested only.
>>
>> Signed-off-by: Suresh Jayaraman 
>> ---
>>  fs/cifs/connect.c |    5 ++++-
>>  1 files changed, 4 insertions(+), 1 deletions(-)
>>
>> diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
>> index 251a17c..c3a2323 100644
>> --- a/fs/cifs/connect.c
>> +++ b/fs/cifs/connect.c
>> @@ -2780,7 +2780,10 @@ try_mount_again:
>>  	if (IS_ERR(tcon)) {
>>  		rc = PTR_ERR(tcon);
>>  		tcon = NULL;
>> -		goto remote_path_check;
>> +		if (rc == -EREMOTEIO)
>> +			goto remote_path_check;
>> +		else
>> +			goto mount_fail_check;
>>  	}
>>  
>>  	/* do not care if following two calls succeed - informational */
> 
> Don't you mean "EREMOTE" here? I've always interpreted "EREMOTEIO" to

(Read the complete message)

[linux-cifs] Re: [PATCH 0/4] cifs: CONFIG_CIFS_EXPERIMENTAL removal (try #2)


  • Subject: Re: [PATCH 0/4] cifs: CONFIG_CIFS_EXPERIMENTAL removal (try #2)
  • From:    Suresh Jayaraman <sjayaraman-l3A5Bk7waGM <at> public.gmane.org>
  • To:      Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA <at> public.gmane.org>
  • Cc:      smfrench-Re5JQEeQqe8AvxtiuMwx3w <at> public.gmane.org, linux-cifs-u79uwXL29TY76Z2rM5mHXA <at> public.gmane.org
  • Date:    2010-12-17 15:28:22
On 12/08/2010 08:33 PM, Jeff Layton wrote:
> This is the second version of this patchset. The changes since the last
> set are:
> 
> 1) The patch to remove "/proc/fs/cifs/Experimental" did not remove the
> deregistration of that file, which caused a warning on rmmod.
> 
> 2) The patch to remove "/proc/fs/cifs/Experimental" now adds a new
> module parameter so that people relying on it to allow zero-copy
> writes with signing have a way to continue using that.
> 
> A modified description of the set follows...
> 
> The CONFIG_CIFS_EXPERIMENTAL KConfig option is the sort of thing that
> gives distro packagers nightmares. The things that live under it are
> impossible to predict for someone who isn't following development
> upstream.

In general, I like the overall idea of removing heavily overloaded
CIFS_EXPERIMENTAL config option. It's true that it was at times hard to
narrow down suspect once this option is enabled.

However, the dependency of a few options on EXPERIMENTAL (fscache and
acl) is not removed. CIFS_FSCACHE can be marked as not dependent on
EXPERIMENTAL. Not sure about CIFS_ACL though.

Can you make this patchset or a subsequent patch accomodates this change
too?


-- 
Suresh Jayaraman
(Read the complete message)

[linux-cifs] Re: strange bottleneck with SMB 2.0


  • Subject: Re: strange bottleneck with SMB 2.0
  • From:    Yale Zhang <yzhang1985 <at> gmail.com>
  • To:      Steve French <smfrench <at> gmail.com>
  • Cc:      "linux-cifs <at> vger.kernel.org" <linux-cifs <at> vger.kernel.org>
  • Date:    2015-08-19 13:41:52
It happens as late as in 4.1.6

On Wed, Aug 19, 2015 at 5:38 AM, Steve French  wrote:
> What kernel version?
>
> On Wed, Aug 19, 2015 at 6:11 AM, Yale Zhang  wrote:
>>
>> SMB developers/users,
>>
>> I'm experiencing a strange bottleneck when my files are mounted as SMB
>> 2.0. When I launch  multiple processes in parallel for benchmarking,
>> only the 1st one starts, and the rest won't start until the 1st one
>> finishes:
>>
>> ---------------------------------------test
>> programs--------------------------------
>> #!/bin/sh
>> ./a.out&
>> ./a.out&
>> ./a.out&
>> wait
>>
>> a.out is just a C program like this:
>>
>> int main()
>> {
>>   printf("greetings\n");
>>   while (true);
>>   return 0;
>> }
>>
>> Apparently, this only affects SMB 2.0. I tried it with SMB 2.1, SMB
>> 3.0, & SMB 3.02, and everything starts in parallel as expected.
>>
>> I'm assuming SMB 3 and especially SMB 2.1 would share a common
(Read the complete message)

[linux-cifs] Linux CIFS client, Windows 2012 CIFS file server => files not found?


  • Subject: Linux CIFS client, Windows 2012 CIFS file server => files not found?
  • From:    Kristian Rink <kawazu428 <at> gmail.com>
  • To:      linux-cifs <at> vger.kernel.org
  • Cc:      None
  • Date:    2015-08-20 13:32:47
Folks;

the last few years we've been locally serving files using a NetApp 
storage system exposing CIFS and several (Windows, Linux) clients 
mounting these shares in order to host data and run an internal business 
application.

The application itself (binaries, libraries, resources, a bunch of ksh 
scripts) entirely lives on the CIFS share. So far (having NetApp CIFS 
mounted), this worked on all machines.

Now, these CIFS shares are to be provided by a Windows 2012 Storage 
Server. Outcome: Linux machines can't run this application anymore. 
Having mounted the W2012 CIFS share, the application won't start 
complaining that some resources (scripts and libraries) are missing, 
even while they are obviously around and also, permission-wise, accessible.

It's difficult to really figure out what happens here. Basically, 
looking at strace output, it seems the application does stat64() one of 
these files which in both cases seems to provide a valid outcome...

stat64("/opt/.../file.oeb", {st_mode=S_IFREG|0755, st_size=36405, ...}) = 0

... but while mounting the share off the NetApp the application works as 
desired, mounting the share off the W2012 server the application will 
terminate here complaining about this particular resource missing.

Vague as it is, does anyone have any idea what could be causing this? 
I've been playing with various parameters of mount.cifs so far, but I'm 
not deep enough into either NetApps nor Windows 2012s understanding of 
CIFS to have an idea what might have changed here...

TIA,
Kristian
--
(Read the complete message)

[linux-cifs] Re: Linux CIFS client, Windows 2012 CIFS file server => files not found?


  • Subject: Re: Linux CIFS client, Windows 2012 CIFS file server => files not found?
  • From:    Steve French <smfrench <at> gmail.com>
  • To:      Kristian Rink <kawazu428 <at> gmail.com>
  • Cc:      "linux-cifs <at> vger.kernel.org" <linux-cifs <at> vger.kernel.org>
  • Date:    2015-08-20 16:11:53
any chance you could send me a small capture file of each (preferably
the smallest possible reproduction scenario so the trace isn't big and
cluttered) so I can compare the two server's responses to see what
might be going on.

(see the "wire captures" section of
https://wiki.samba.org/index.php/LinuxCIFS_troubleshooting)

On Thu, Aug 20, 2015 at 8:32 AM, Kristian Rink  wrote:
> Folks;
>
> the last few years we've been locally serving files using a NetApp storage
> system exposing CIFS and several (Windows, Linux) clients mounting these
> shares in order to host data and run an internal business application.
>
> The application itself (binaries, libraries, resources, a bunch of ksh
> scripts) entirely lives on the CIFS share. So far (having NetApp CIFS
> mounted), this worked on all machines.
>
> Now, these CIFS shares are to be provided by a Windows 2012 Storage Server.
> Outcome: Linux machines can't run this application anymore. Having mounted
> the W2012 CIFS share, the application won't start complaining that some
> resources (scripts and libraries) are missing, even while they are obviously
> around and also, permission-wise, accessible.
>
> It's difficult to really figure out what happens here. Basically, looking at
> strace output, it seems the application does stat64() one of these files
> which in both cases seems to provide a valid outcome...
>
> stat64("/opt/.../file.oeb", {st_mode=S_IFREG|0755, st_size=36405, ...}) = 0
>
> ... but while mounting the share off the NetApp the application works as
> desired, mounting the share off the W2012 server the application will
> terminate here complaining about this particular resource missing.
>
(Read the complete message)

[linux-cifs] Re: Linux CIFS client, Windows 2012 CIFS file server => files not found?


  • Subject: Re: Linux CIFS client, Windows 2012 CIFS file server => files not found?
  • From:    Kristian Rink <kawazu428 <at> gmail.com>
  • To:      Steve French <smfrench <at> gmail.com>
  • Cc:      "linux-cifs <at> vger.kernel.org" <linux-cifs <at> vger.kernel.org>
  • Date:    2015-08-20 19:36:57
Hi Steve;

and first off, thanks loads for your feedback.

Am 20.08.2015 um 18:11 schrieb Steve French:
> any chance you could send me a small capture file of each (preferably
> the smallest possible reproduction scenario so the trace isn't big and
> cluttered) so I can compare the two server's responses to see what
> might be going on.

Sure, it's easy to reproduce, and I ended up with two pcap files. Mind 
if I send these off-list, or should I rather upload them anywhere?

Thanks again and all the best,
Kristian
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Read the complete message)

[linux-cifs] Re: Linux CIFS client, Windows 2012 CIFS file server => files not found?


  • Subject: Re: Linux CIFS client, Windows 2012 CIFS file server => files not found?
  • From:    Steve French <smfrench <at> gmail.com>
  • To:      Kristian Rink <kawazu428 <at> gmail.com>
  • Cc:      "linux-cifs <at> vger.kernel.org" <linux-cifs <at> vger.kernel.org>
  • Date:    2015-08-20 20:23:03
On Thu, Aug 20, 2015 at 2:36 PM, Kristian Rink  wrote:
> Hi Steve;
>
> and first off, thanks loads for your feedback.
>
> Am 20.08.2015 um 18:11 schrieb Steve French:
>>
>> any chance you could send me a small capture file of each (preferably
>> the smallest possible reproduction scenario so the trace isn't big and
>> cluttered) so I can compare the two server's responses to see what
>> might be going on.
>
>
> Sure, it's easy to reproduce, and I ended up with two pcap files.

Last thing in the trace is a parallelized read with lots of reads in
flight at once which should be ok and I do see a response.

Two obvious things to ask:

1) What dialect are you using when you mount to Windows?  It looks
like SMB2.0 (and would be MUCH better to use SMB2.1 or SMB3 or
SMB3.02, or even CIFS when mounting to Windows, SMB2.0 is old and does
not support large reads/writes and it looks like it is failing )
rather than the default CIFS.  To NetApp you are mounting using CIFS
(not SMB2 or SMB3) which seems to work ok for your workload looking at
the trace.

Note that you should try the same dialect on both the mount to NetApp
and Windows to make the comparison easier:  e.g. after -o in the mount
command specify "vers=2.1" or "vers=3.0" (or don't specify any vers
(or "vers=1.0") and it should default to cifs)

2) Are there any things logged in the message log on the Linux client
(type "dmesg" to see what is logged) by cifs.ko during the failure on
(Read the complete message)
[Previous Thread]