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>