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: Re: [9fans] 9pfuse and O_APPEND
Date: Wed, 24 Dec 2008 22:04:53 -0800	[thread overview]
Message-ID: <5B0D7CF9-2F33-45B1-B445-6A4EDFBF8BEE@sun.com> (raw)
In-Reply-To: <42fe5d2488144155692f859a62a64b07@quanstro.net>

On Dec 21, 2008, at 6:45 AM, erik quanstrom wrote:
>>> 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.
>
> i use "in general" to mean the exact opposite of what
> you are saying here; there is a case where it could happen.

Well, it is quite difficult to deny an audience to Mr. Murphy, isn't
it? ;-)

>> 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).
>
> okay, so you're using DMAPPEND like sbrk(2).

That's a pretty good analogy, yes.

> clients caring about the offset of this hunk of the file?
> that is, the same problem malloc has in a multi-threaded app
> with sbrk.

yes. But unlike what happens in malloc's case -- these regions
are *not* for clients to work with. They are for dumping data.
When there's fragmentation you can be given an offset to
write to, but that's mostly an optimization. What really needs
to happen is very simple -- the data needs to be dumped.

> why not put the things your storing in seperate files, or of there
> are an unwielded number of things, use some sort of clone interface
> to create a new $thing that the server carefully maps into the big
> file?

These are quite reasonable suggestions. Thanks.

In fact, this entire thread was quite helpful to me, since it made me
realize
that my expectation of what constitutes the most common use for
APPEND-like semantics are NOT what most of you guys have in mind.

That's fair. But let me flip a question then, a bit: what do you all use
DMAPPEND for? What's are the examples of the most appropriate
usage for it in existing Plan9 software?

Thanks,
Roman.



  parent reply	other threads:[~2008-12-25  6:04 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
2008-12-21 14:45     ` erik quanstrom
2008-12-22 10:02       ` roger peppe
2008-12-25  6:04       ` Roman Shaposhnik [this message]
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=5B0D7CF9-2F33-45B1-B445-6A4EDFBF8BEE@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).