hi, > YAMAMOTO Takashi <[email protected]> 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 > [email protected]
