Re: [PATCH] Re: zero-filed page on VOP_PUTPAGES

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

hi,

> YAMAMOTO Takashi <yamt%mwd.biglobe.ne.jp@localhost> wrote:
> 
>> > +                       rvap->va_size = MAX(rvap->va_size, vp->v_size);
>> 
>> couldn't it be a problem if the size of the file is shrinked by the server?
> 
> In that case, ou client will not see the file being shrunk until it
> forgets about it and looks it up again. I guess it means that when you
> hold a file open, you do not see it being shrunk by another client. 
> 
> That may be annoying, though I have trouble to find a situation where it
> would cause problems. A mail system, perhaps, with clients being SMTP
> and IMAP daemons? But in such a setup, you use locking so that only a
> single client opens a mailbox, otherwise you breaak everything.

if you implement eg. nfs as a puffs server, you can't rely on such
a strong locking anyway.

i have a puffs based experimental filesystem which can be at least
read-only mounted by another client.  it performs locking in the backend
and it appears to be less broken than "break everything" :-)

> 
>> how about stopping using FAF for SETATTR?
>> i guess puffs_msg_setcall can be used instead.
> 
> I am not sure it would fix all corner cases. Basically the problem is
> that synchronisation of kernel and filesystem view of file size are not
> atomic. Getting rid of the FAF for SETATTR will not prevent a race with
> another thread that tests or sets file size. 

if you use non-FAF synchronous SETATTR, vnode lock prevents the race,
doesn't it?  it might be a performance hit, tho.

alternatively, using puffs_msg_setcall, i think you can make GETATTR
reliably know if there's a pending SETATTR or not.
if there's a pending SETATTR, GETATTR can ignore a part of the reply
from the file server and returns the kernel's idea of the file attributes
instead.

YAMAMOTO Takashi

> 
> -- 
> Emmanuel Dreyfus
> http://hcpnet.free.fr/pubz
> manu%netbsd.org@localhost