Date: Sat, 20 Jul 2002 09:53:23 +0930 (CST) From: Richard Sharpe <rsharpe@ns.aus.com> To: Julian Elischer <julian@elischer.org> Cc: <freebsd-hackers@freebsd.org>, <jra@samba.org> Subject: Re: Any problems with Using sendfile Message-ID: <Pine.LNX.4.33.0207200951190.4109-100000@ns.aus.com> In-Reply-To: <Pine.BSF.4.21.0207191531190.91009-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 19 Jul 2002, Julian Elischer wrote: > the samba people said that there is a reason they can not use any sendfile > 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. > On Sat, 20 Jul 2002, Richard Sharpe wrote: > > > Hi, > > > > I did some testing a couple of days ago with sendfile under FreeBSD and > > Samba, and observed that in pulling 500MB of data from files on a server I > > could achieve about 45MB/s over GigE (I have a problem in my switch, I > > think) but that CPU utilization was at 100% without sendfile and 50% with > > sendfile. > > > > This is a big improvement, but there are potential problems. These > > problems are due to fact that once you start sending, if anything changes, > > you cannot stop and say oops, I screwed up. If you promised to send 64kB, > > you have to send that or drop the connection. > > > > The problem is exacerbated by the fact that the Linux sendfile call does > > not seem to allow you to specify the header on the call, so you are forced > > to send the header from userspace and the data from the kernel, and you > > therefor introduce a window during which things can go wrong. For example, > > the file can be truncated or deleted, and I don't think SMB allows you to > > send zeros for parts of the file that are not there. This is especially an > > issue if you don't have kernel oplocks and you have UNIX users sharing > > files with Windows users. > > > > The way Samba does this normally is that it assembles the data in > > userspace and then sends the response. If a problem occurs, it can > > determine this before sending anything at all, and can send an > > error response instead and does not need to drop the connection. > > > > However, FreeBSD's sendfile implementation allows you to specify the > > header to be sent in the call, and I believe that it also locks the vnode > > prior to trying anything so you are protected against the file changing > > under you. > > > > The only other thing that it could perhaps do is to pin all the pages > > before trying to send anything. Thus, if any error occurs, it can return > > to the user saying, sorry, I could not do this, you send an error message. > > That is, errors are handled in a recoverable way. > > > > The question is, does it gain you anything by demanding that the pages > > involved (up to 16) be pinned before starting to write on the socket? It > > increases pressure on memory, but it might be that the only problems that > > could occur mean that really bad things have happened anyway (like the > > file system has gone because the disk has died), so it might be that there > > is no need to be worried about this aspect. > > > > Are there any comments from here? > > > > 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 > > > -- 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.0207200951190.4109-100000>