Date: Sat, 20 Jul 2002 18:05:12 +0930 (CST) From: Richard Sharpe <rsharpe@ns.aus.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Julian Elischer <julian@elischer.org>, <freebsd-hackers@FreeBSD.ORG>, <jra@samba.org> Subject: Re: Any problems with Using sendfile Message-ID: <Pine.LNX.4.33.0207201757540.5058-100000@ns.aus.com> In-Reply-To: <200207200547.g6K5lxoI011811@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 19 Jul 2002, Matthew Dillon wrote: > :... > :> 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 While this option turned up while I was looking at a benchmark :-), I think it is more general than that, because it avoids copying data to and from userspace just to get the data to the user. NFS went into the kernel to avoid this, but we do not have that luxury, I think. Being able to handle more clients, especially out of buffer cache when many of them are reading the same file, because there is more CPU to share around, makes a lot of sense from a NAS vendor's point of view. If the data is somewhere in memory, why force Samba to copy it twice? Indeed, even if it has to be brought into memory off of disk, again why force Samba to copy it twice. What I am concerned with is whether the current mechanisms protect us sufficiently that the area we are working on (max 64kB to 128kB at most) will not be changed until we have got rid of the data. > 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. Well, we have implemented kernel-level oplocks, and can rely on that to protect us, but for people who don't have kernel-level oplocks and who want to make better use of their CPU, it would be great to be able to do this. Regards ----- Richard Sharpe, rsharpe@ns.aus.com, rsharpe@samba.org, sharpe@ethereal.com 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?Pine.LNX.4.33.0207201757540.5058-100000>