From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sat, 20 Dec 2008 21:05:29 -0800 From: "Roman V. Shaposhnik" In-reply-to: <13426df10812191300p3fe94845g6033505f4008c9d0@mail.gmail.com> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-id: <1229835929.11463.55.camel@goose.sun.com> MIME-version: 1.0 Content-type: text/plain Content-transfer-encoding: 7BIT References: <59EE20C6-0043-4517-ADDA-4BC5C4D24D74@sun.com> <13426df10812191300p3fe94845g6033505f4008c9d0@mail.gmail.com> Subject: Re: [9fans] 9pfuse and O_APPEND Topicbox-Message-UUID: 6af4489e-ead4-11e9-9d60-3106f5b1d025 On Fri, 2008-12-19 at 13:00 -0800, ron minnich wrote: > > * 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? As with any software -- it would be pretty difficult for me to prevent somebody from doing that, but in general -- no. > If so then you can do all the abuse of the protocol you want but you can't make > any guarantees ... That's a good point. Its funny but some bits of software we produce are also NFS-unfriendly. They will warn you if you are trying to use NFS. I guess I might do the same. > 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". As I have indicated some time ago -- its NOT a problem for me to have X clients do random access and Y clients doing DMAPPEND on the same file. The integrity of the file will NOT be affected. It is protected by the chunk_size that ALL I/O is coming to me at. The only thing that I have to guarantee at the server end is that all of the writes coming from clients asking for DMAPPEND will, in fact, be written at the offset corresponding to the EOF (whatever that might be at the moment when the I/O arrives). There's no "doing their best" involved at the clients from the set Y. They simply indicate that ALL of their I/O should be DMAPPEND. Server has ALL the power to make it happen. In fact, in this rather long thread, nobody yet has come up with a convincing argument of why the above scenario wouldn't work. > And your 9pfuse server is really a client in the end. Just to be clear: 9pfuse is PURE client in my particular case. I might decide to enchance it to honor the O_APPEND, but it will not make it less of a client. Of course, whatever I do, I will NOT be emulating O_APPEND. There will be no "do my best" involved. > So you may get it almost working but there are no guarantees. The only thing that can break the guarantee is the server serving the NFS mounted files. > It's interesting to watch network wires melt trying to manage server > client callbacks so that "posix semantics" work ... Mmm. Yes, but the scheme I've just described will be exactly what POSIX mandates for O_APPEND. Whether it'll melt the wires remains to be seen. Thanks, Roman.