> 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: da...@l8s.co.uk
