Re: VOP_GETATTR: locking protocol change proposal

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

> yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi) wrote:
>> > <...>
>> > 
>> > 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.
>> > 
>> > <...>
>> 
>> 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.
> 
> I wonder if it is worth having a separate VOP for that, which would
> retrieve a subset of vattr without lock held.  There are potentially
> more uses in the tree.

while it's good to have VOP_GETATTR take a mask to specify a set of
requested attributes, i don't think it's worth to have a serparete VOP
for this.  (PR/30250 is related)

IMO we should make unlocked VOP calls safe (against revoke and umount -f)
and put VOP_GETATTR locking back into filesystem internal.

YAMAMOTO Takashi

> 
> -- 
> Mindaugas