On Tue, May 07, 2013 at 01:04:35AM -0600, Scott Long wrote: > > On May 6, 2013, at 2:05 PM, Konstantin Belousov <kostik...@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.
pgpMmQUBvgcdd.pgp
Description: PGP signature