svn commit: r250027 - head/sys/kern

[Konstantin Belousov]

On Tue, May 07, 2013 at 01:04:35AM -0600, Scott Long wrote:
> 
> On May 6, 2013, at 2:05 PM, Konstantin Belousov <kostikbel at 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
> >>> 
> >>> 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.
> >> 
> >> Doesn't it add extra I/O to query file system about file's attributes?
> >> If it does, does it matter here?
> > 
> > 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.

Typical there is quantified by the filesystem type. If you read my
previous response, you should note that I claimed that UFS never performs
disk access when executing VOP_GETATTR(). The UFS inode is always kept
in memory while vnode is not reclaimed.

For NFS indeed, if the attribute cache is expired, the rpc is fired.

> 
> > 
> > E.g. UFS always keeps the unpacked inode in memory for any non-reclaimed
> > vnode.  For NFS, vnode usually caches the attributes.
> > 
> > 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?
This might be done, I will look at this later.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20130507/798df322/attachment.sig>