On Thu, Dec 18, 2008 at 3:34 PM, Roman Shaposhnik <r...@sun.com> wrote:
> > So far, I see the following choices for myself: > * follow what v9fs does and emulate it with llseek(...SEEK_END). Not > ideal, > since it doesn't always guarantee POSIX sematics, but way better > than nothing. and it won't scale and it can't be guaranteed to work at scale. What really ought to happen is that the unix world should stop making these guarantees that can not be honored. Like that's ever going to happen :-) > * emulate per-FID DMAPPEND by letting the server (which I also control) > accept Qid > modifications on wstat. My understanding is that existing 9P servers > would simply > reply with Rerror and I can then fallback onto llsek, perhaps. > Border-line abuse of > the protocol. is your 9p server ever going to be running on an nfs-mounted partition? If so then you can do all the abuse of the protocol you want but you can't make any guarantees ... this is a problem. > * reserve (unit)-1 offset in writes as an indication to append to the end > of the file. Really > seems like an abuse of the protocol :-( I don't know. This seems the least unlikeable. Right now the use of -1 offset to the kernel means "write at the current offset". Now I find myself unable to remember if that -1 would be seen on the wire -- I just don't remember but I'm sure the smart people do. But you still can't guarantee it. That's the problem -- if append mode is an intrinsic property of the file, honored and managed at the server that really owns that file, that's a difference in kind from clients who are doing their best to "write at end". And your 9pfuse server is really a client in the end. So you may get it almost working but there are no guarantees. It's interesting to watch network wires melt trying to manage server client callbacks so that "posix semantics" work ... ron
