Re: VOP_GETATTR: locking protocol change proposal

[David Laight <david%l8s.co.uk@localhost>]

On Tue, Nov 15, 2011 at 03:44:34AM +0000, YAMAMOTO Takashi wrote:
> hi,
> 
> > The vnode locking requirement currently allows to call VOP_GETATTR()
> > on an unlocked vnode.  This is orthogonal to all other operations that
> > read data or metadata and want at least a shared lock.  It also asks
> > for trouble as the attributes may change while the operation is in
> > progress.
> > 
> > With the attached diff the locking protocol requests at least a shared
> > lock and all calls to VOP_GETATTR() outside of file systems respect it.
> > 
> > The calls from file systems need review (NFS server is suspicious at least).
> > 
> > I will commit this diff around Oct 14 if noone objects.
> 
> postgresql assumes instant lseek(SEEK_END) to get the size of
> their heap files.
> 
>       http://rhaas.blogspot.com/2011/11/linux-lseek-scalability.html
> 
> as fsync etc keeps the vnode lock during i/o, it might cause severe
> performance regression.
> 
> YAMAMOTO Takashi

Something worse than lock contention must be happening in linux.
Since fstat() - which will also need the inode lock - was faster
than lseek().

I'd have thought that code run with the mutex held would be much
shorter than the rest of the code path - unless the application
is hard-looping on the lseek().

        David

-- 
David Laight: david%l8s.co.uk@localhost