Re: Errors popping up under heavy load

On Tue, 24 Feb 2009 06:17:48 -0600
Michael Muratet <mmuratet <at> hudsonalpha.org> wrote:

> Greetings
> 
> I have Promise 48TB RAID system connected to MacPro and CIFS mounted  
> to a Dell 1950 8-core running RedHat Enterprise 3. I was not so much  
> worried about security, but it did seem to perform better than NFS,  
> for instance. It has worked well up until now. We recently had to  
> migrate some large apps from the Mac to the linux box because a vendor  
> no longer supports the Mac which puts a lot of traffic through the  
> mount. Yesterday we starting seeing errors:
> 

Sorry for the late response...

> Feb 23 09:25:59 srv-cf1 kernel:  CIFS VFS: No response to cmd 46 mid  
> 62979
> Feb 23 09:25:59 srv-cf1 kernel:  CIFS VFS: No response to cmd 46 mid  
> 62980

Client sent an error and timed out before the server responded...

> Feb 23 09:25:59 srv-cf1 kernel:  CIFS VFS: Send error in read = -11
> Feb 23 09:25:59 srv-cf1 kernel:  CIFS VFS: Send error in read = -11

We tried to send on the socket, but couldn't. -EAGAIN == -11, which
means "try again later".

> Feb 23 09:25:59 srv-cf1 kernel:  CIFS VFS: No response to cmd 47 mid  

Re: Errors popping up under heavy load

On Mar 3, 2009, at 6:06 AM, Jeff Layton wrote:

> On Tue, 24 Feb 2009 06:17:48 -0600
> Michael Muratet <mmuratet <at> hudsonalpha.org> wrote:
>
>> Greetings
>>
>> I have Promise 48TB RAID system connected to MacPro and CIFS mounted
>> to a Dell 1950 8-core running RedHat Enterprise 3. I was not so much
>> worried about security, but it did seem to perform better than NFS,
>> for instance. It has worked well up until now. We recently had to
>> migrate some large apps from the Mac to the linux box because a  
>> vendor
>> no longer supports the Mac which puts a lot of traffic through the
>> mount. Yesterday we starting seeing errors:
>>
>
> Sorry for the late response...

Jeff

No worries, thanks for the response
>
>
>> Feb 23 09:25:59 srv-cf1 kernel:  CIFS VFS: No response to cmd 46 mid
>> 62979
>> Feb 23 09:25:59 srv-cf1 kernel:  CIFS VFS: No response to cmd 46 mid
>> 62980
>

Re: Errors popping up under heavy load

On Tue, 03 Mar 2009 06:32:58 -0600
Michael Muratet <mikemuratet <at> me.com> wrote:

>
> Linux srv-cf1.haib.org 2.6.9-55.ELsmp #1 SMP Fri Apr 20 16:36:54 EDT  
> 2007 x86_64 x86_64 x86_64 GNU/Linux
> 

That kernel is pretty old (almost 2 years). In fact, that kernel has a
known memory corruption bug that can crop up under those conditions, so
at the very least you want to patch up to the latest -55.0.z kernel.

Even better would be to patch to something in the RHEL 4.7 series since
those kernels have a lot of other fixes as well.

--

-- 
Jeff Layton <jlayton <at> redhat.com>

Re: Errors popping up under heavy load

I know that the windows server may drop the connection if there is more 
than around 150 outstanding requests from the same IP - it assumes the 
client is abusive, I think. (I don't know if this is just per ip or per 
ip/mid combination).

Before it drops the connection it may throttle responses.

The client may need to do some resource management.

Sam

* Michael Muratet wrote, On 03/03/09 12:32:
>
> On Mar 3, 2009, at 6:06 AM, Jeff Layton wrote:
>
>> On Tue, 24 Feb 2009 06:17:48 -0600
>> Michael Muratet <mmuratet <at> hudsonalpha.org> wrote:
>>
>>> Greetings
>>>
>>> I have Promise 48TB RAID system connected to MacPro and CIFS mounted
>>> to a Dell 1950 8-core running RedHat Enterprise 3. I was not so much
>>> worried about security, but it did seem to perform better than NFS,
>>> for instance. It has worked well up until now. We recently had to
>>> migrate some large apps from the Mac to the linux box because a vendor
>>> no longer supports the Mac which puts a lot of traffic through the
>>> mount. Yesterday we starting seeing errors:
>>>
>>
>> Sorry for the late response...

Re: [PATCH 0/2] posix locks behaviour on Windows server

What is about my patch?

--
Best regards,
Pavel Shilovsky.

Re: mkdir -p problem

What's about this problem?

--

-- 
Best regards,
Pavel Shilovsky.

Re: [PATCH] cifs: set SYNCHRONIZE bit when opening for cifs_rename_pending_delete

On Sat, 28 Feb 2009 12:59:02 -0500
Jeff Layton <jlayton <at> redhat.com> wrote:

> From: Jeff Layton <jlayton <at> tupile.poochiereds.net>
> 
> Discovered at Connectathon 2009...
> 
> Some servers apparently require that the filehandle passed to a trans2
> rename be opened with the SYNCHRONIZE bit set. If it isn't then the
> server may throw back an error.
> 
> This patch makes the cifs-capable connectathon tests pass when run
> against BlueArc servers. I've also heard rumors that Win2k requires
> that the file be opened with this bit set as well, but I haven't
> confirmed it.
> 
> Signed-off-by: Jeff Layton <jlayton <at> redhat.com>

After doing a bit more research on this, I think this patch is not
correct. The SYNCHRONIZE bit should never be sent on over the wire
calls. If BlueArc's servers require this then it's bug on their end.
Please disregard this patch.

> ---
>  fs/cifs/inode.c |    7 ++++---
>  1 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
> index 050552c..a80d86d 100644
> --- a/fs/cifs/inode.c

Re: [PATCH] cifs: set SYNCHRONIZE bit when opening for cifs_rename_pending_delete

On Tue, Mar 3, 2009 at 1:37 PM, Jeff Layton <jlayton <at> redhat.com> wrote:
> On Sat, 28 Feb 2009 12:59:02 -0500
> Jeff Layton <jlayton <at> redhat.com> wrote:
>
>> From: Jeff Layton <jlayton <at> tupile.poochiereds.net>
>>
>> Discovered at Connectathon 2009...
>>
>> Some servers apparently require that the filehandle passed to a trans2
>> rename be opened with the SYNCHRONIZE bit set. If it isn't then the
>> server may throw back an error.
>>
>> This patch makes the cifs-capable connectathon tests pass when run
>> against BlueArc servers. I've also heard rumors that Win2k requires
>> that the file be opened with this bit set as well, but I haven't
>> confirmed it.

I agree
I have confirmed that there are a couple of cases when Windows clients can
send this bit, but the bit is supposed to be cleared, and none of
those operations
required this bit be set (and in fact their documentation forbids it to be set).

--

-- 
Thanks,

Steve

[CIFS] [PATCH] warn on EINVAL error on posix open, and turn off posix open if server broken for this call

Attached is patch to workaround the problem found in posix open to
Samba versions 3.3.1 and earlier
(create works, but open would fail with invalid parameter) - it
disables requests to try posix open after
a first failure.

--

-- 
Thanks,

Steve

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client <at> lists.samba.org
https://lists.samba.org/mailman/listinfo/linux-cifs-client

Re: [CIFS] [PATCH] warn on EINVAL error on posix open, and turn off posix open if server broken for this call

On Wed, 2009-03-04 at 13:02 -0600, Steve French wrote:
> Attached is patch to workaround the problem found in posix open to
> Samba versions 3.3.1 and earlier
> (create works, but open would fail with invalid parameter) - it
> disables requests to try posix open after
> a first failure.

Why do you completely disable posix opens ?
Wouldn't it make sense to reopen only when it fails ?
After all when you create new files it works correctly.

Simo.

--

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo <at> samba.org>
Principal Software Engineer at Red Hat, Inc. <simo <at> redhat.com>