[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

NFS4 file transfers fail or are very slow



Hello guys,

I have recently installed Debian Stretch 9.3 on a new PC and I'd just like to provide some NFS shares for other Linux machines in the LAN (1GBit). With small files everything works fine, but if I try to copy, e.g., a 7GB file with rsync it starts with a high transmission rate above 160MB/s and then goes down to around 70-90MB/s. After a random but short time there's no more progress going on for about 10-15 seconds. When the process then continues, the speed goes down to around 20MB/s and then up to about 200MB/s. It seems to continue transferring data, but rsync gives me an error message in the end.

On another client I experience the same, but there the last rate lies around 85MB/s instead of the 200MB/s from above. I guess this comes because the first PC has a SSD and the latter only a HDD. On the first client runs Arch Linux, on the latter ubuntu mate 16.04. Exactly the same share is able to write more than 105MB/s via SMB/CIFS, so I would expect an NFS speed in a similar range.

My configurations files look as follows.

/etc/fstab on server:
/dev/disk/by-label/vol1  /vol1  ext4 defaults,nofail,user_xattr,noexec,usrjquota=aquota.usr,grpjquota=aquota.grp,jqfmt=vfsv0,acl 0 2
/vol1/temp  /export/temp  none  bind,nofail  0 0

/etc/exports on server:
/export/temp  192.168.192.0/24(fsid=1,rw,subtree_check,secure)
# NFSv4 pseudo filesystem root
/export 192.168.192.0/24(ro,fsid=0,root_squash,no_subtree_check,hide)

/etc/default/nfs-kernel-server on server:
RPCNFSDCOUNT=64
RPCNFSDPRIORITY=0
RPCMOUNTDOPTS="--manage-gids"
NEED_SVCGSSD=
RPCSVCGSSDOPTS=

/etc/fstab on clients:
192.168.192.10:/temp  /mnt/temp  nfs rw,bg,intr,soft,users,noauto,_netdev,proto=tcp,retry=3,timeo=10  0 0

I tried different export and mount options, but nothing helped to get stable transfer. Sometimes the transmission finishes successfully, but with a low rate (<60MB/s).

What can cause this problem?

Best regards,
Michael


Reply to: