Date: Wed, 11 Jan 2012 14:29:54 -0500 From: "Mikhail T." <mi+thun@aldan.algebra.com> To: Bob Friesenhahn <bfriesen@simple.dallas.tx.us> Cc: fs@freebsd.org Subject: Re: How to best send files over network? Message-ID: <4F0DE332.5040804@aldan.algebra.com> In-Reply-To: <alpine.GSO.2.01.1201111220570.5538@freddy.simplesystems.org> References: <1235110182.47136.1326298038118.JavaMail.root@erie.cs.uoguelph.ca> <alpine.GSO.2.01.1201111220570.5538@freddy.simplesystems.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11.01.2012 13:29, Bob Friesenhahn wrote:
> Yes, I am definitely talking about the receive (or the writing end).
Well, this topic is of no concern to me right now -- I'm sending to clients
already written (and embedded in firmwares), hence the explicit subject line :-)
> The main advantage of using sendfile() seems to be to keep the file data from
> needing to transit a user-space program. This is a noble goal but
> circumstances have changed (i.e. bottlenecks have moved) since sendfile() was
> invented.
Even if other things involved in sending a file cost more, memory copying is
still not free...
> If FreeBSD sendfile is using memory mapping in its implementation, then that
> is definitely bad for zfs.
In September K. Macy claimed on this mailing list, that sending from mmap is
over twice faster than sendfile, if the file is on ZFS:
http://freebsd.1045724.n5.nabble.com/ZFS-lighttpd2-sendfile-too-high-IO-td4793886.html
Bob replied to that, actually, so he must remember the discussion :)
Though I find this sorry state of sendfile() rather disheartening, reading the
above thread got me thinking about using a different method for different
filesystems. But if mmap/write is never (i.e. for both UFS and ZFS) any worse
than sendfile, then I can simply always use mmap in all cases. And this is, what
I wanted to discuss -- I thought, in some cases, sendfile can arrange for data
to go from the disk controller to the network card directly...
Yours,
-mi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F0DE332.5040804>