SMB from a Mac : Preparing copy quite long

[Alkivi]

Hello,

This is a screencast of a behaviour we have on our Freenas.
https://www.dropbox.com/s/k3m7noutctend4u/test-deplacement-bg.mov?dl=0

The Mac and the server are in Gb/s ethernet link.

The files are quite small (less than 10MB)

Have you got any ideas about what we can do ?

Our server :
Build FreeNAS-9.3-STABLE-201602031011
Platform Intel(R) Xeon(R) CPU E5-2609 v2 @ 2.50GHz
Memory 65432MB
System Time Thu Mar 17 11:42:45 CET 2016
Uptime 11:42AM up 33 days, 22:03, 0 users
Load Average 0.09, 0.10, 0.12

 

[anodos]

If you don't mind, post a debug tarball. 'system' -> 'advanced' -> 'save debug'. Note that it may contain sensitive information about your network (look over the contents yourself). If you feel squeamish, PM it to me.

 

[Alkivi]

Thx for your help :)

I've just sent you a PM with the debug file.

 

[anodos]

Thx for your help :)

I've just sent you a PM with the debug file.

It's hard to say because you have debug set to 10 (more reading than i like to do), but it may be that samba is struggling to deal with OSX resource forks on the files.

I'd test the following options:
0) reduce logging level
1) create a test dataset with VFS_streams_depot enabled on the CIFS share instead of VFS_streams_xattr. This will allow samba to accommodate larger resource forks. Try to replicate the problem.
2) on a different machine, try to reproduce the problem in FreeNAS 9.10 nightly with vfs_fruit enabled.

Note that streams_depot and streams_xattr store file metadata in very different ways. This means that in the future (with FreeNAS 9.10) moving data from a share with vfs_streams_depot enabled to one with vfs_fruit (which uses a combination of netatalk and streams_xattr) will have to be done through samba and not through 'cp' in the CLI.

FYI, I noticed you are using dpx files. You might also want to take a look at vfs_preopen.