[NBLUG/talk] Warning in logs..

[Steve Johnson]

rsync is not an option in this case, neither is upgrading the kernel.. Long
story behind that :)  The kernel is 2.6.9, so all though it is not the
newest, it isn't to bad off..

I'm using tar to get the data to the CIFS mount, so I think I just need to
copy the data back and see if the data checks out okay and then go from
there.

This same system is running on several machines with out any problems, and
most the machines are running similar kernels..  so its hard to point at the
kernel in this case.. Now I did read somewhere that if the host of the cifs
mount is busy when the file copy is going on that it might be the cause of
the error, so I may just need to see whats going on there  and attack it
from that side..

Thanks for the reply, it helped shed some light on this issue.

-Steve


On Wed, Feb 23, 2011 at 10:13 PM, <cecrops at herring.sandwich.net> wrote:

> On Tue, 22 Feb 2011, Steve Johnson wrote:
>
>> Hey guys, I keep seeing this error in my logs, I understand what might be
>> causing it, but what I am wondering, since it is a warning, and not an
>> error, and there is only 1.. Does this mean the system re-tried and got
>> past
>> it?  This happens during a large file copy that happens nightly.. Do I
>> need
>> to worry about data integrity?
>>
>> --------------------- Kernel Begin ------------------------
>>
>> WARNING:  Kernel Errors Present
>>   CIFS VFS: Error -4 sending data ...:  1 Time(s)
>>
>> ---------------------- Kernel End -------------------------
>>
>
>
> I looked around the CIFS code and see no sign that it retries in this case,
> so I would worry. Is it possible to rsync the data?
>
>
> This posting says that problem can be caused by old versions of CIFS
> running in non-blocking mode, and suggests a kernel update as a resolution:
> http://lists.samba.org/archive/linux-cifs-client/2009-April/004482.html
>
>
> Notes that you may or may not find useful:
>
> The error message comes from smb_send() in transport.c of cifs. Other parts
> of transport.c check the returns from kernel_sendmsg for the negatives of
> errno.h errors, so the -4 could be EINTR 4, interrupted system call.
>
> What happens when RC receives a negative number in SendReceive() in
> transport.c:
>
> rc = smb_send(ses->server->ssocket, in_buf, in_buf->smb_buf_length,
>     (struct sockaddr *) &(ses->server->addr.sockAddr));
>
> if(rc < 0) {
>        DeleteMidQEntry(midQ);
>        up(&ses->server->tcpSem);
>
>        /* If not lock req, update # of requests on wire to server */
>        if(long_op < 3) {
>                atomic_dec(&ses->server->inFlight);
>                wake_up(&ses->server->request_q);
>        }
>        return rc;
> }
>
> It looks like it just cuts out, but I can't tell what the other gears will
> be doing. It might be up to the userspace program to detect failure and
> retry.
>
> In the kernel, it looks like something is going wrong around
> wait_on_sync_kiocb() but I could be mistaken.
>
> _______________________________________________
> talk mailing list
> talk at nblug.org
> http://nblug.org/cgi-bin/mailman/listinfo/talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nblug.org/pipermail/talk/attachments/20110224/1b3551ac/attachment.htm>