Matthew Dillon wrote:
> NFS read performance is primarily client-driven. usually setting the
> read-ahead (for example, mount_nfs -a 4) is the biggest performance driver
> for reads. OpenBSD defaults to -a 1 which is basically no read-ahead. I
> suggest -a 4 at a minimum. Also make sure the r
NFS read performance is primarily client-driven. usually setting the
read-ahead (for example, mount_nfs -a 4) is the biggest performance driver
for reads. OpenBSD defaults to -a 1 which is basically no read-ahead. I
suggest -a 4 at a minimum. Also make sure the read block size is at least
8192
This is a very interested thread. I just played little bit with dd on my
desktop machine running OpenBSD 5.9 amd64 NFS-client. NFS server runs on
DragonFly BSD 4.4.2. No optimization of any kind has been done. My home
network is 1 Gigabit. I will play over the weekend with various block
sizes and t
I seem to be experiencing this as well, but I have no access to the client
side as it is a wireless camera. Is there anything that can be done on the
server side?
-Steve S.
Thanks, Brian!You are right. The default value of 65536 for wsize and
rsize seems bad for debian client. Lower values gave me very good results
(it seems the lower the value the better the responsiveness).I finally
stopped at value 4096. Seems working.--Best regardsRodin Maxim14.04.2016,
15:25,
I ran into that same behavior with a Debian client before lowering the
readsize and writesize in the NFS mount options (they defaulted to 64K I
believe). Try starting at 8096 and working your way up until you find the
failure point.
Brian Conway
Software Engineer, Owner
RCE Software, LLC
I was us
I was using nfs service on OpenBSD (amd64) since version 5.6.
The whole setup process repeats the steps in official FAQ on the OpenBSD's
homepage.
The problem was and remains (now in version 5.9 amd64):
in TCP mode the upload speed is about 20-30MB/s
which is quite acceptable for my needs, but t
7 matches
Mail list logo