From: "Roman V. Shaposhnik" <rvs@sun.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] 9pfuse and O_APPEND
Date: Sat, 20 Dec 2008 21:05:29 -0800 [thread overview]
Message-ID: <1229835929.11463.55.camel@goose.sun.com> (raw)
In-Reply-To: <13426df10812191300p3fe94845g6033505f4008c9d0@mail.gmail.com>
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.
next prev parent reply other threads:[~2008-12-21 5:05 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-18 23:34 Roman Shaposhnik
2008-12-18 23:57 ` Russ Cox
2008-12-19 0:03 ` ron minnich
2008-12-19 3:06 ` Roman Shaposhnik
2008-12-19 3:26 ` ron minnich
2008-12-19 3:59 ` Roman Shaposhnik
2008-12-19 16:44 ` ron minnich
2008-12-19 19:21 ` Anthony Sorace
2008-12-19 19:31 ` erik quanstrom
2008-12-19 19:41 ` ron minnich
2008-12-19 19:59 ` Roman Shaposhnik
2008-12-19 20:06 ` erik quanstrom
2008-12-19 20:18 ` Charles Forsyth
2008-12-21 5:08 ` Roman V. Shaposhnik
2008-12-19 3:03 ` Roman Shaposhnik
2008-12-19 3:43 ` erik quanstrom
2008-12-19 3:54 ` Roman Shaposhnik
2008-12-19 4:13 ` geoff
2008-12-19 8:23 ` Russ Cox
2008-12-19 19:49 ` Roman Shaposhnik
2008-12-19 19:56 ` erik quanstrom
2008-12-19 20:10 ` Roman Shaposhnik
2008-12-19 20:22 ` erik quanstrom
2008-12-19 20:02 ` ron minnich
2008-12-19 14:21 ` erik quanstrom
2008-12-19 21:00 ` ron minnich
2008-12-19 21:32 ` Charles Forsyth
2008-12-19 21:29 ` ron minnich
2008-12-21 5:05 ` Roman V. Shaposhnik [this message]
2008-12-21 14:45 ` erik quanstrom
2008-12-22 10:02 ` roger peppe
2008-12-25 6:04 ` Roman Shaposhnik
2008-12-25 6:33 ` erik quanstrom
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1229835929.11463.55.camel@goose.sun.com \
--to=rvs@sun.com \
--cc=9fans@9fans.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).