[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 <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
> Emmanuel Dreyfus
Main Index |
Thread Index |