Date: Fri, 19 Jul 2002 22:47:59 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Richard Sharpe <rsharpe@ns.aus.com> Cc: Julian Elischer <julian@elischer.org>, <freebsd-hackers@FreeBSD.ORG>, <jra@samba.org> Subject: Re: Any problems with Using sendfile Message-ID: <200207200547.g6K5lxoI011811@apollo.backplane.com> References: <Pine.LNX.4.33.0207200951190.4109-100000@ns.aus.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:... :> implementation. :> they explained it to me once and I think I got it. but I have since :> forgotten it. It was something to do with what happens if the session is :> aborted or broken in some way but I forget the details. : :Yes, it has to do with what happens when you start sendfile on a file, and :someone truncates the file from under you ... : :You can protect against it with OpLocks. If you are concerned about UNIX :users truncating the file, then you need kernel oplocks or some other :mechanism to ensure that the file, at least in the area you are trying to :sendfile, cannot change until you have sent it. : :I am one of the Samba guys. People have had similar problems with Apache dying because it mmap()'s the file it is trying to serve and something else comes along and copies over or truncates the file. At least insofar as local filesystems and Apache goes, the easiest solution is to update a file by copying to file.NEW and then renaming it over the original, rather then truncating and copying over the original. I think the use of mmap() and even sendfile() by programs like Apache is simply catering to benchmarks. Apache really doesn't need to use mmap() and probably shouldn't use it by default precisely because of the lack of control over changes made to the file(s) being served. Most production servers are I/O limited, not cpu-limited, and using read() vs mmap() makes no difference whatsoever to the number of physical disk seeks that actually occur. mmap() has its uses... News and MTA subsystems, managed file accesses by things like DBMs, and so forth. But basic file serving? It just isn't a necessity. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200207200547.g6K5lxoI011811>