I/O Error on CIFS Mounts?

[fukawi2]

While trying to write files from a CIFS mount to a USB drive, I get I/O Errors on the majority of files.

~ $ attic init /tmp/test
Initializing repository at "/tmp/test"
Encryption NOT enabled.
Use the "--encryption=passphrase|keyfile" to enable encryption.
~ $ attic create /tmp/test::1 /media/dozer/photo/Phil/2014/140525\ -\ Hillcrest\ Station\ Opening/
Initializing cache...
attic: /media/dozer/photo/Phil/2014/140525 - Hillcrest Station Opening/DSC_0258.JPG: [Errno 5] Input/output error
ttic: /media/dozer/photo/Phil/2014/140525 - Hillcrest Station Opening/DSC_0259.JPG: [Errno 5] Input/output error
attic: /media/dozer/photo/Phil/2014/140525 - Hillcrest Station Opening/DSC_0260.JPG: [Errno 5] Input/output error
attic: Exiting with failure status due to previous errors

Those files are NOT added to the archive:

~ $ attic list /tmp/test
1                                    Sat Jul 26 22:48:38 2014
~ $ attic list /tmp/test::1
drwxrwxrwx fukawi2 fukawi2        0 May 26 19:00 media/dozer/photo/Phil/2014/140525 - Hillcrest Station Opening
-rwxrwxrwx fukawi2 fukawi2  5261846 May 25 13:16 media/dozer/photo/Phil/2014/140525 - Hillcrest Station Opening/DSC_0262.JPG

There is nothing wrong with the files -- I can open/edit them just fine using other tools:

~ $ tar cvPWf /tmp/test.tar /media/dozer/photo/Phil/2014/140525\ -\ Hillcrest\ Station\ Opening/
/media/dozer/photo/Phil/2014/140525 - Hillcrest Station Opening/
/media/dozer/photo/Phil/2014/140525 - Hillcrest Station Opening/DSC_0258.JPG
/media/dozer/photo/Phil/2014/140525 - Hillcrest Station Opening/DSC_0259.JPG
/media/dozer/photo/Phil/2014/140525 - Hillcrest Station Opening/DSC_0260.JPG
/media/dozer/photo/Phil/2014/140525 - Hillcrest Station Opening/DSC_0262.JPG
Verify /media/dozer/photo/Phil/2014/140525 - Hillcrest Station Opening/
Verify /media/dozer/photo/Phil/2014/140525 - Hillcrest Station Opening/DSC_0258.JPG
Verify /media/dozer/photo/Phil/2014/140525 - Hillcrest Station Opening/DSC_0259.JPG
Verify /media/dozer/photo/Phil/2014/140525 - Hillcrest Station Opening/DSC_0260.JPG
Verify /media/dozer/photo/Phil/2014/140525 - Hillcrest Station Opening/DSC_0262.JPG

The CIFS mount is a Synology NAS, mounted with these options:

//dozer/shared on /media/dozer/ type cifs (rw,relatime,vers=1.0,cache=strict,username=fukawi2,domain=DOZER,uid=1537,forceuid,gid=1537,forcegid,addr=2001:db8::1,unix,posixpaths,serverino,acl,rsize=1048576,wsize=1048576,actimeo=1)

(IPv6 address sanitized)

A strace on the process shows that it seems to be aborting through a read() call, but given tar (with verify) works fine I'm not sure what is being done differently.

[jborg]

That's strange. I have pretty much the same setup myself (cifs mounted synology nas) and it seems to work just fine.

Is it always the same files that triggers these errors?

Are you able to attach a strace log showing these failing read() calls?

[fukawi2]

This appears to be the relevant section:

llistxattr("/media/dozer/photo/Phil/2014/140525 - Hillcrest Station Opening", NULL, 0) = 0
lgetxattr("/media/dozer/photo/Phil/2014/140525 - Hillcrest Station Opening", "system.posix_acl_access", 0x0, 0) = -1 EOPNOTSUPP (Operatio     n not supported)
openat(AT_FDCWD, "/media/dozer/photo/Phil/2014/140525 - Hillcrest Station Opening", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 7
getdents(7, /* 28 entries */, 32768)    = 880
getdents(7, /* 0 entries */, 32768)     = 0
close(7)                                = 0
lstat("/media/dozer/photo/Phil/2014/140525 - Hillcrest Station Opening/DSC_0258.JPG", {st_mode=S_IFREG|0777, st_size=4032022, ...}) = 0
open("/home/fukawi2/.cache/attic/4bf07c769cf64ef82b871e0bb8ee4418d68ad6c6ffdb2b853a80b4d669abd67f/files", O_RDONLY|O_CLOEXEC) = 7
fstat(7, {st_mode=S_IFREG|0640, st_size=0, ...}) = 0
ioctl(7, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0x7fff7d6e3c50) = -1 ENOTTY (Inappropriate ioctl for device)
fstat(7, {st_mode=S_IFREG|0640, st_size=0, ...}) = 0
lseek(7, 0, SEEK_CUR)                   = 0
brk(0x13dc000)                          = 0x13dc000
read(7, "", 65536)                      = 0
close(7)                                = 0
open("/media/dozer/photo/Phil/2014/140525 - Hillcrest Station Opening/DSC_0258.JPG", O_RDONLY|O_CLOEXEC) = 7
fstat(7, {st_mode=S_IFREG|0777, st_size=4032022, ...}) = 0
ioctl(7, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0x7fff7d6e3e90) = -1 ENOTTY (Inappropriate ioctl for device)
fstat(7, {st_mode=S_IFREG|0777, st_size=4032022, ...}) = 0
lseek(7, 0, SEEK_CUR)                   = 0
mmap(NULL, 10489856, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc0a9289000
mmap(NULL, 10489856, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc0a8888000
read(7, "\377\330\377\341\377\376Exif\0\0MM\0*\0\0\0\10\0\v\1\17\0\2\0\0\0\22\0\0"..., 10485760) = 3145728
read(7, 0x7fc0a8b88030, 7340032)        = -1 EIO (Input/output error)
munmap(0x7fc0a8888000, 10489856)        = 0
munmap(0x7fc0a9289000, 10489856)        = 0
close(7)                        

What distro are you on and what mount options are you using?

[jborg]

What distro are you on and what mount options are you using?

I'm using Arch Linux (Linux 3.15.7) and exactly the same mount options.

Judging by the strace output there must be some problem with this particular CIFS mount. read() is not supposed to return EIO on a functional file system.

[fukawi2]

I just retested after -Syu and still same behaviour. I'm buggered if I know then :-/

[jborg]

How reproducible is it? Does it always happen on the same file/files?

If so, I could write a minimal test program that uses the exact same syscalls and see if that also triggers it

[fukawi2]

It's 100% reproducible so far. Happy to test something :)

[iskunk]

Hi, I've seen problems before where reads/writes on CIFS fail if they are larger than 64MB. Here, it's reading exactly 3MB (3145728 = 3 * 2^20) before it fails, so something similar may be going on. What if you tried reading 1-2MB at a time instead of 10?

[fukawi2]

No dice; I tried with my Fonts directory (nothing over 1mb) and same errors:

$ attic create /tmp/test::1 /media/dozer/photo/TestAtticSource/
Initializing cache...
attic: /media/dozer/photo/TestAtticSource/28 Days Later.ttf: [Errno 5] Input/output error
attic: /media/dozer/photo/TestAtticSource/ABITE.ttf: [Errno 5] Input/output error
attic: /media/dozer/photo/TestAtticSource/Anonymous Pro B.ttf: [Errno 5] Input/output error
attic: /media/dozer/photo/TestAtticSource/Anonymous Pro BI.ttf: [Errno 5] Input/output error
attic: /media/dozer/photo/TestAtticSource/Anonymous Pro I.ttf: [Errno 5] Input/output error
attic: /media/dozer/photo/TestAtticSource/Anonymous Pro.ttf: [Errno 5] Input/output error
<LOTS MORE FONTS HERE>
attic: /media/dozer/photo/TestAtticSource/rayando.ttf: [Errno 5] Input/output error
attic: /media/dozer/photo/TestAtticSource/sidewalk.ttf: [Errno 5] Input/output error
attic: /media/dozer/photo/TestAtticSource/times_new_yorker.ttf: [Errno 5] Input/output error
attic: /media/dozer/photo/TestAtticSource/trashco.ttf: [Errno 5] Input/output error
attic: Exiting with failure status due to previous errors
/media/dozer/photo/TestAtticSource $

[ThomasWaldmann]

Can this still be reproduced with a current attic release?

[fukawi2]

I'm away on holiday at the moment until mid-November. I will re-test and advise results when I'm back.

[ThomasWaldmann]

Any news?

[nguillaumin]

Sorry to hijack this thread but I'm having exactly the same issue, although not using attic but other programs.

I'm also running Arch (4.8.13-1-ARCH) and using a Synology NAS. Using strace gives the same type of output, which I can reproduce just using the file command (e.g. strace file /path/to/file/on/nas/). Similarly, it works fine if I open the file with another program like the picture viewer.

I wrote a small test program to try to read the file with different buffer sizes, which lead me to play with the rsize mount option, and setting a smaller value (e.g. 16384) seems to make it go away (although it has a performance impact).

That used to work fine though, so I'm wondering if something changed in the CIFS client programs / libraries (cifs-utils) which wouldn't be compatible with older Synology models? Perhaps this rsize option wasn't set before and was defaulting to a smaller value? Perhaps the other programs that work use a smaller buffer size?

Which Synology models do you guys have? I have a DS209+II with DSM 4.2-3211.

Could you try adjusting the rsize value and see if that helps?

[strarsis]

I had a similar issue with git on CIFS, I was able to fix it by adding cache=none to the CIFS mount options in '/etc/fstab' (and remounted).