Date: Thu, 23 Jan 2014 22:18:02 -0500 (EST) From: Rick Macklem <rmacklem@uoguelph.ca> To: J David <j.david.lists@gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: Terrible NFS performance under 9.2-RELEASE? Message-ID: <58591523.15519962.1390533482068.JavaMail.root@uoguelph.ca> In-Reply-To: <CABXB=RR5NgRpqXA8XQDks3HhxC6QQW3aG%2BsH4BUxFL7kbFuJ_g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
J David wrote: > Rick, > > If iozone wants to do a 4kiB write in the middle of a 1GiB file and > the rsize/wsize are both set to 32kiB, does NFS read a 32k block over > the wire, modify it, and send it back? Or does it just send "write > this 4k at offset X" and let the server sort it out? > This depends on the client. For FreeBSD, if the rest of the 32K block has not been modified recently, it will mark that 4K byte range as dirty (b_dirtyoff, b_dirtyend in "struct buf") and it will do a 4Kbyte write at the correct offset. For Linux, I don't know. (Take a look at a wireshark trace of it and find out. You could write a simple program that does this once, so that the packet trace is short. Sorry, I couldn't resist;-) An NFS server must always be able to handle a write of any length starting at any byte offset. The performance effects on the server are largely defined by the type of exported file system on the server. I didn't mention this before, but using UFS will give you more realistic results than using mfs, since mfs would never be used for a real NFS server and never gets tested as an exported NFS file system. rick > Some of the tests I'm running are producing very strange results, and > I'm trying to understand what might be happening. > > Thanks! > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?58591523.15519962.1390533482068.JavaMail.root>