Dolphin copy/move over NFS4 failing on large file sizes.

[oshunluvr]

Saw this for the first time yesterday: It appears when I use Dolphin and attempt to copy a large (near or over 1GB) file over my network using NFS4 connection. The amount that makes it through is variable. On files near 1 GB, I can sometimes get a good transfer if I reattempt it a couple times, but my attempts with a 2GB file fail every time. almost every time. After a number of attempts, the 2GB file went through a couple times in a row.

I believe this is a Dolphin issue because at the CLI the cp commands work flawlessly. BTW, SAMBA also worked, albeit noticeably slower than NFS4 and to/from local disks all worked. So it appears to be related to NFS4 and Dolphin somehow. I'm getting no error messages (when launching Dolphin from the CLI) just a pop-up saying the copy failed.

I just wondered if anyone else has noticed this or if it's just my system...

[wizard10000]

Got some thoughts

I routinely copy large files using NFS and although I haven't had any issues with dolphin I normally use mc because I like to monitor transfer speed. Target netbook only has a 100Mb NIC so I expect to see transfer rates around 8MB/sec. I really haven't seen any speed difference between dolphin and mc, though.

Are you mounting your NFS shares as sync or async? Even though I take a little speed hit I prefer using sync but that's just me. Part of the reason CIFS is slower than NFS is samba runs in a single thread while NFS is multithreaded.

Also, NFS block size. After much testing I set rsize and wsize both to 16384 bytes, so I'm transferring in 16k blocks. I didn't see much if any improvement going bigger than that.

Hope this helps -

edit: I use autofs to mount NFS shares; maybe my config will help you a little - my /etc/auto.master (this goes on the target machine)

/nfsmount /etc/auto.nfs --ghost

# /nfsmount is the name of my mount point and that directory must exist.  
# autofs will create the other mount points and mount the shares on demand.  
# I think they stay connected for ten minutes after last use then they unmount.  
# This can cause slowdowns with shutdown or reboot if the machine has to wait 
# for the NFS connections to time out.  (a minute and a half on my machine).

My /etc/auto.nfs (also goes on the target machine) -

netbook-etc         -fstype=nfs,rw,nosuid,soft,rsize=16384,wsize=16384,intr,noatime 192.168.1.102:/etc
netbook-home        -fstype=nfs,rw,nosuid,soft,rsize=16384,wsize=16384,intr,noatime 192.168.1.102:/home/wizard
netbook-external    -fstype=nfs,rw,nosuid,soft,rsize=16384,wsize=16384,intr,noatime 192.168.1.102:/mnt/external

and /etc/exports (from the machine hosting the shares) -

/etc                192.168.1.0/24(rw,sync,no_subtree_check)
/home/wizard        192.168.1.0/24(rw,sync,no_subtree_check)
/mnt/external       192.168.1.0/24(rw,sync,no_subtree_check)

[oshunluvr]

Both computers, desktop and server, are "fixed" so I use fstab to mount:

/etc/fstab (client)

[FONT=monospace][COLOR=#000000]server:/ /shared nfs4 auto,bg,soft,timeo=5,retrans=5,actimeo=10,retry=5,users,rsize=65536,wsize=65536,noatime,x-systemd.automount 0 0[/COLOR]

[/FONT]

/etc/exports (server)

/exports 192.168.1.0/24(rw,fsid=0,crossmnt,no_subtree_check,async,secure,nohide,all_squash,anonuid=65534,anongid=560)

This has been running this way for years, but I've upgraded to KDEneon so I wonder if its related to kernel version or some other variable.

[wizard10000]

...This has been running this way for years, but I've upgraded to KDEneon so I wonder if its related to kernel version or some other variable.

Yeah - I'm sure you know as well as I that there are no random events in information technology; everything has a cause.

I'm running Debian Unstable so I can't duplicate the Neon error. It might be interesting to run glances on both machines - in a terminal window on the source and an ssh session on the target and see if there's a bottleneck you can find; I'm wondering if iowait is off the charts and if so, whether that's network or disk.

Also - wonder if you're getting network dropouts; if you're dropping packets for an extended period something's gonna disconnect. I had rather poor performance with a 64k rsize/wsize, so maybe temporarily lowering them and using sync instead of async might help diagnose the issue.

On my network if the target gets disconnected during a file transfer dolphin will hang; probably because I'm displaying a directory that's no longer available.

That's about all the thoughts I have but there's a buncha smart people here - maybe someone else has ideas

[oshunluvr]

Yeah, I'll try going back to 32k first and see if it continues. I prefer the performance using async, but if that turns out to be the cause I'll have to revert to sync.

[oshunluvr]

I changed to 32k r/w and just did 5 copies of files between 1.5 and 2.2 GB and all went smoothly. Hoping this is all I have to do - Thanks for the hint!