tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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


> YAMAMOTO Takashi <> 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


> -- 
> Emmanuel Dreyfus

Home | Main Index | Thread Index | Old Index