Date: Sat, 20 Jul 2002 08:44:32 +0930 (CST) From: Richard Sharpe <rsharpe@ns.aus.com> To: <freebsd-hackers@freebsd.org> Subject: Any problems with Using sendfile Message-ID: <Pine.LNX.4.33.0207200834570.4109-100000@ns.aus.com> In-Reply-To: <20020719102130.E19831@va.samba.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.33.0207200834570.4109-100000>