Date: Tue, 7 May 2013 01:04:35 -0600 From: Scott Long <scott4long@yahoo.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Pawel Jakub Dawidek <pjd@FreeBSD.org> Subject: Re: svn commit: r250027 - head/sys/kern Message-ID: <166D5005-9B80-4B72-BF6C-80DA0F5D6DCD@yahoo.com> In-Reply-To: <20130506200530.GD3047@kib.kiev.ua> References: <201304281912.r3SJC9bL030636@svn.freebsd.org> <20130506181610.GA1390@garage.freebsd.pl> <20130506200530.GD3047@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 6, 2013, at 2:05 PM, Konstantin Belousov <kostikbel@gmail.com> = wrote: > On Mon, May 06, 2013 at 08:16:11PM +0200, Pawel Jakub Dawidek wrote: >> On Sun, Apr 28, 2013 at 07:12:09PM +0000, Konstantin Belousov wrote: >>> Author: kib >>> Date: Sun Apr 28 19:12:09 2013 >>> New Revision: 250027 >>> URL: http://svnweb.freebsd.org/changeset/base/250027 >>>=20 >>> Log: >>> Eliminate the layering violation in the kern_sendfile(). When = quering >>> the file size, use VOP_GETATTR() instead of accessing vnode = vm_object >>> un_pager.vnp.vnp_size. >>=20 >> Doesn't it add extra I/O to query file system about file's = attributes? >> If it does, does it matter here? >=20 > It should not, typically. Whenever you say the word "typically", I get nervous. I take this to = mean that under pressure, the syscall may likely synchronously block to complete this = call. If so, then it makes sendfile() pretty much unusable for us at Netflix, and it = means that we will either need to revert this or resort to a hack. >=20 > E.g. UFS always keeps the unpacked inode in memory for any = non-reclaimed > vnode. For NFS, vnode usually caches the attributes. >=20 > Anyway, using VOP_GETATTR() is the only sanctioned way to get file = size. > Directly accessing vm_object assumes that vm_object is of OBJT_VNODE = type, > which is no longer true. How about just testing for this assumption and only performing the = VOP_GETATTR if it's not true? Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?166D5005-9B80-4B72-BF6C-80DA0F5D6DCD>