[linux-cifs-client] Error while copying data from CIFS share

[Shirish Pargaonkar]

On 7/29/08, Marko Käning <mk362 at mch.osram.de> wrote:
> Hi,
>
> this is once again about my problems with error messages like this (was
> thread with subject "(no subject)" before):
>
> ---
> Unusual System Events
> =-=-=-=-=-=-=-=-=-=-=
> Jul 28 23:28:17 flmpc35 kernel:  CIFS VFS: No response to cmd 46 mid 47778
> Jul 28 23:28:17 flmpc35 kernel:  CIFS VFS: Send error in read = -11
> Jul 28 23:28:17 flmpc35 kernel:  CIFS VFS: No response to cmd 46 mid 47777
> Jul 28 23:28:17 flmpc35 kernel:  CIFS VFS: Send error in read = -11
> Jul 28 23:28:17 flmpc35 kernel:  CIFS VFS: No response to cmd 46 mid 47776
> Jul 28 23:28:17 flmpc35 kernel:  CIFS VFS: Send error in read = -11
> Jul 28 23:28:17 flmpc35 kernel:  CIFS VFS: No response to cmd 4 mid 47779
> Jul 28 23:28:17 flmpc35 kernel:  CIFS VFS: Send error in Close = -11
> Jul 28 23:28:17 flmpc35 kernel:  CIFS VFS: No response to cmd 46 mid 47780
> Jul 28 23:28:17 flmpc35 kernel:  CIFS VFS: Send error in read = -11
> Jul 28 23:28:17 flmpc35 kernel:  CIFS VFS: No response for cmd 50 mid 47783
> Jul 28 23:28:17 flmpc35 kernel:  CIFS VFS: No response for cmd 50 mid 47782
> Jul 28 23:28:17 flmpc35 kernel:  CIFS VFS: No response for cmd 50 mid 47781
> Jul 28 23:28:17 flmpc35 kernel:  CIFS VFS: Send error in read = -9
> ---
>
> Difference to before is this time that one of my 40000 backed-up files
> turned out to be different from its original, as my backup scripts told
> me:
>
> ---
> kaening at flmpc35:~> LANG=C diff /backup/unpack/svnrepos/2005-2008/db/revs/1124 /home/svnrepos/2005-2008/db/revs/1124
> Files /backup/unpack/svnrepos/2005-2008/db/revs/1124 and
> /home/svnrepos/2005-2008/db/revs/1124 differ
> kaening at flmpc35:~>
> ---
>
> and indeed, the retrieved file is actually shorter than the original:
>
> ---
> kaening at flmpc35:~> ls -l /backup/unpack/svnrepos/2005-2008/db/revs/1124 /home/svnrepos/2005-2008/db/revs/1124
> -rw-rw-r-- 1 root svncvs1 23850000  1. Jul 11:09 /backup/unpack/svnrepos/2005-2008/db/revs/1124
> -rw-rw-r-- 1 root svncvs1 23853313  1. Jul 11:09 /home/svnrepos/2005-2008/db/revs/1124
> kaening at flmpc35:~>
> ---
>
> 23850000 is quite characteristic, isn't it?
>
> Well, the original in /home is of course of correct length. Turns out that
> the CIFS share on /backup-remote is also of correct length when I unpack
> it:
>
> ---
> kaening at flmpc35:~/temp/bz> cp /backup-remote/backups/flmpc35/2008.07.28_21.01.47/svnrepos/2005-2008/db/revs/1124.bz2 .
> kaening at flmpc35:~/temp/bz> bunzip2 1124.bz2
> kaening at flmpc35:~/temp/bz> l
> insgesamt 23332
> drwxr-xr-x  2 kaening users     4096 29. Jul 10:42 ./
> drwxr-xr-x 13 kaening users     4096 29. Jul 10:21 ../
> -rw-r--r--  1 kaening users 23853313 29. Jul 10:42 1124
> kaening at flmpc35:~/temp/bz>
> ---
>
> so only the read failed during verification of my backup. I could not find
> any signs of failure in my logs while storeBackup was retrieving the
> faulty file from the CIFS share. Very odd! I'd have expected that there
> would be an error message when the file could not be transferred to the
> unpack directory. But there was none. If the error occurred just during
> the bunzip2 stage I'd have expected an error from bunzip2 popping up. But
> nothing like this happened...
>
> This is the first time that a file wasn't properly restored after about a
> dozen of backup-verifications... Odd!
>
>
> I just issued "echo 1 > /proc/fs/cifs/cifsFYI" and hope that the error is
> going to occur some time soon again so that I can give more information
> from my kernel's log.
>
> Meanwhile I hope that some of you might come up with an idea.
>
> Regards,
> Marko
> _______________________________________________
> linux-cifs-client mailing list
> linux-cifs-client at lists.samba.org
> https://lists.samba.org/mailman/listinfo/linux-cifs-client
>

I have seen cases where during file copy, cifs encounters EAGAIN and
drops those pages and so we have 0 filled holes on the destination files i.e.
data is now different than the source file.
cifs needs to handle this error (EAGAINs returned by kernel_sendmsg
in smb_send2).
Do you see the same problem i.e. 0 filled pages?
Not sure whether you can run xxd command on this file and see
whether there are 0 filled pages.

Regards,

Shirish