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&#39;t to bad off..<br><br>I&#39;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.  <br>
<br>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..<br>
<br>Thanks for the reply, it helped shed some light on this issue.<br><br>-Steve<br> <br><br><div class="gmail_quote">On Wed, Feb 23, 2011 at 10:13 PM,  <span dir="ltr">&lt;<a href="mailto:cecrops@herring.sandwich.net">cecrops@herring.sandwich.net</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="h5">On Tue, 22 Feb 2011, Steve Johnson wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hey guys, I keep seeing this error in my logs, I understand what might be<br>
causing it, but what I am wondering, since it is a warning, and not an<br>
error, and there is only 1.. Does this mean the system re-tried and got past<br>
it?  This happens during a large file copy that happens nightly.. Do I need<br>
to worry about data integrity?<br>
<br>
--------------------- Kernel Begin ------------------------<br>
<br>
WARNING:  Kernel Errors Present<br>
   CIFS VFS: Error -4 sending data ...:  1 Time(s)<br>
<br>
---------------------- Kernel End -------------------------<br>
</blockquote>
<br>
<br></div></div>
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?<br>
<br>
<br>
This posting says that problem can be caused by old versions of CIFS<br>
running in non-blocking mode, and suggests a kernel update as a resolution:<br>
<a href="http://lists.samba.org/archive/linux-cifs-client/2009-April/004482.html" target="_blank">http://lists.samba.org/archive/linux-cifs-client/2009-April/004482.html</a><br>
<br>
<br>
Notes that you may or may not find useful:<br>
<br>
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.<br>

<br>
What happens when RC receives a negative number in SendReceive() in<br>
transport.c:<br>
<br>
rc = smb_send(ses-&gt;server-&gt;ssocket, in_buf, in_buf-&gt;smb_buf_length,<br>
     (struct sockaddr *) &amp;(ses-&gt;server-&gt;addr.sockAddr));<br>
<br>
if(rc &lt; 0) {<br>
        DeleteMidQEntry(midQ);<br>
        up(&amp;ses-&gt;server-&gt;tcpSem);<br>
<br>
        /* If not lock req, update # of requests on wire to server */<br>
        if(long_op &lt; 3) {<br>
                atomic_dec(&amp;ses-&gt;server-&gt;inFlight);<br>
                wake_up(&amp;ses-&gt;server-&gt;request_q);<br>
        }<br>
        return rc;<br>
}<br>
<br>
It looks like it just cuts out, but I can&#39;t tell what the other gears will be doing. It might be up to the userspace program to detect failure and retry.<br>
<br>
In the kernel, it looks like something is going wrong around<br>
wait_on_sync_kiocb() but I could be mistaken.<br>
<br>
_______________________________________________<br>
talk mailing list<br>
<a href="mailto:talk@nblug.org" target="_blank">talk@nblug.org</a><br>
<a href="http://nblug.org/cgi-bin/mailman/listinfo/talk" target="_blank">http://nblug.org/cgi-bin/mailman/listinfo/talk</a><br>
</blockquote></div><br>