Re: VOP_GETATTR: locking protocol change proposal

[yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi)]

> 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().

your assumption (fstat uses the same lock) is just wrong.

> 
> 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().

postgresql folks improved their code to the point this can be a problem.

YAMAMOTO Takashi

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