9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Roman Shaposhnik <rvs@sun.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: [9fans] 9pfuse and O_APPEND
Date: Thu, 18 Dec 2008 15:34:34 -0800	[thread overview]
Message-ID: <59EE20C6-0043-4517-ADDA-4BC5C4D24D74@sun.com> (raw)

I guess this is mainly a question for Russ: I'm using 9pfuse for a
proof-of-concept project here at Sun and it all works quite
well. My goal is to avoid the 9P2000.u route and use 9P2000
semantics  as much as possible, yet allow most of the POSIX
FS functionality to simply work.

In order to do that, I have to extend 9pfuse somewhat. In most
cases my code could be considered "complimentary" to the
core of 9pfuse, but there's one case which seems to be common
enough to  warrant some discussion and potential
changes to the core.

The question has to do with O_APPEND flag. POSIX apps
seem to use it quite frequently (most notably bash uses it
for the most basic of redirections  >>) but 9pfuse doesn't
really have any support for it:

main.c:_fuseopen
        /*
	 * Could translate but not standard 9P:
	 *	O_DIRECT -> ODIRECT
	 *	O_NONBLOCK -> ONONBLOCK
	 *	O_APPEND -> OAPPEND
	 */
	if(flags){
		fprint(2, "unexpected open flags %#uo", (uint)in->flags);
		replyfuseerrno(m, EACCES);
		return;
	}

So here's my question: is there any consensus on how to best
emulate it?

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.
    * 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.
    * 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 :-(

There's also a way for me to handle the situation the way I intend to
handle the
rest of POSIX goo: have a dedicated tree with a special aname. But in
case
of a so common operation it seems to be a bit of an overkill.

Thus, I'd really love to hear suggestions that might help integrate
that bit of code back into
the 9pfuse proper.

Thanks,
Roman.



             reply	other threads:[~2008-12-18 23:34 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-18 23:34 Roman Shaposhnik [this message]
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
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=59EE20C6-0043-4517-ADDA-4BC5C4D24D74@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).