> 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?
i think log files are the cannonical use of append-only files.
mbox style mailboxes also use append-only sematics fo
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
On Sun, Dec 21, 2008 at 2:45 PM, erik quanstrom wrote:
> okay, so you're using DMAPPEND like sbrk(2). how do you avoid
> clients caring about the address of this new hunk of memory?^u
> clients caring about the offset of this hunk of the file?
> that is, the same problem malloc has in a multi-thr
> > 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
On Fri, 2008-12-19 at 20:18 +, Charles Forsyth wrote:
> >And nobody yet cared to give a concrete explanation of why it might be a bad
> >idea.
>
> what's the application you've got in mind?
Legacy ones :-( At the moment -- they are homegrown databases. And yes,
as Erik pointed out -- they lo
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 l
On Fri, Dec 19, 2008 at 1:32 PM, Charles Forsyth wrote:
>> if that -1 would be seen on the wire
>
> no. it's just a flag to select the code path that provides the offset,
> and entirely internal (just as well).
>
>
I figured as much. Oh well. Sorry, Roman.
ron
On Thu, Dec 18, 2008 at 3:34 PM, Roman Shaposhnik 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
> if that -1 would be seen on the wire
no. it's just a flag to select the code path that provides the offset,
and entirely internal (just as well).
> It is difficult to answer your question without knowing what rewrite
> actually does and how mailboxes are structured. But in an imaginary
> world where a mailbox is a list of constant sized blocks (size a bunch of simultaneous appends and rewrites of existing blocks
> would work perfectly well.
On Dec 19, 2008, at 11:56 AM, erik quanstrom wrote:
Two questions:
1. But before I ask this one: I don't deny that per-file append-
only
is *extremely* useful. My question is a different one: what is
the danger of N clients accesing the file X in append-only mode
and M clients ac
> And how is it different from what I was suggesting: A Fid that makes
> *all* writes be at EOF? You want to write at EOF? Easy -- just use
> that pre-negotiated Fid that was opened with (now non existent)
> DMAPPEND flag added to the mode. You want a random-access
> write AT THE SAME TIME? Easy --
>And nobody yet cared to give a concrete explanation of why it might be a bad
>idea.
what's the application you've got in mind?
On Fri, Dec 19, 2008 at 11:49 AM, Roman Shaposhnik wrote:
> Two questions:
> 1. But before I ask this one: I don't deny that per-file append-only
>is *extremely* useful. My question is a different one: what is
>the danger of N clients accesing the file X in append-only mode
>and M c
On Dec 19, 2008, at 8:44 AM, ron minnich wrote:
On Thu, Dec 18, 2008 at 7:59 PM, Roman Shaposhnik wrote:
On Dec 18, 2008, at 7:26 PM, ron minnich wrote:
On Thu, Dec 18, 2008 at 7:06 PM, Roman Shaposhnik
wrote:
Its fun, yes. But I believe this is more of a testament to the
statelessness
o
> Two questions:
> 1. But before I ask this one: I don't deny that per-file append-only
> is *extremely* useful. My question is a different one: what is
> the danger of N clients accesing the file X in append-only mode
> and M clients accesing it in random access mode? Could you,
On Dec 19, 2008, at 12:23 AM, Russ Cox wrote:
Append-only and exclusive-use are properties of files
and need to be enforced uniformly across all clients
to be meaningful. They must be per-file, not per-fd.
Two questions:
1. But before I ask this one: I don't deny that per-file append-only
On Fri, Dec 19, 2008 at 11:21 AM, Anthony Sorace wrote:
>> client by definition knows more than the server.
>
> i assume you mean "knows less"? the server knows where EOF is and
> which files to enforce append-only on. your #1 seems to only exist
> because the client doesn't have that info.
in st
On Fri Dec 19 14:24:52 EST 2008, ano...@gmail.com wrote:
> > client by definition knows more than the server.
>
> i assume you mean "knows less"? the server knows where EOF is and
> which files to enforce append-only on. your #1 seems to only exist
> because the client doesn't have that info.
i t
> client by definition knows more than the server.
i assume you mean "knows less"? the server knows where EOF is and
which files to enforce append-only on. your #1 seems to only exist
because the client doesn't have that info.
On Thu, Dec 18, 2008 at 7:59 PM, Roman Shaposhnik wrote:
> On Dec 18, 2008, at 7:26 PM, ron minnich wrote:
>>
>> On Thu, Dec 18, 2008 at 7:06 PM, Roman Shaposhnik wrote:
>>>
>>> Its fun, yes. But I believe this is more of a testament to the
>>> statelessness
>>> of the NFS
>>> plus the fact that
> The places that DMAPPEND is used most commonly are log files and mail
> boxes.
mailboxes are append only, however
deleting a message requires rewriting
the mailbox, which isn't possible. so
a temporary mbox is written, has its
mode tweaked and then replaces the
mbox. L.mbox is exclusive open a
Append-only and exclusive-use are properties of files
and need to be enforced uniformly across all clients
to be meaningful. They must be per-file, not per-fd.
Russ
The places that DMAPPEND is used most commonly are log files and mail
boxes. In both cases, I don't want the decision of whether to
truncate or append left to the whims of some program. I want writes
to append, by god, and DMAPPEND on actual disk-based file servers such
as fossil and fs does that
On Dec 18, 2008, at 7:26 PM, ron minnich wrote:
On Thu, Dec 18, 2008 at 7:06 PM, Roman Shaposhnik wrote:
Its fun, yes. But I believe this is more of a testament to the
statelessness
of the NFS
plus the fact that the "end of file" is not a well defined offset
(unlike
beginning of
the file).
On Dec 18, 2008, at 7:43 PM, erik quanstrom wrote:
Agreed. Now, here's a bit that I still don't quite
understand: Plan9 does have DMAPPEND on
a per-Qid basis. Why was it decided not to
have it on a per-Fid basis (which would match
POSIX semantics 100%)?
The way I understand -- DMAPPEND is just a
> Agreed. Now, here's a bit that I still don't quite
> understand: Plan9 does have DMAPPEND on
> a per-Qid basis. Why was it decided not to
> have it on a per-Fid basis (which would match
> POSIX semantics 100%)?
>
> The way I understand -- DMAPPEND is just a hint
> to the server to *alway* ignore
On Thu, Dec 18, 2008 at 7:06 PM, Roman Shaposhnik wrote:
> Its fun, yes. But I believe this is more of a testament to the statelessness
> of the NFS
> plus the fact that the "end of file" is not a well defined offset (unlike
> beginning of
> the file).
>
no, it's even worse with stateful systems
On Dec 18, 2008, at 4:03 PM, ron minnich wrote:
On Thu, Dec 18, 2008 at 3:57 PM, Russ Cox wrote:
I would just seek to the end.
That's fine unless you have multiple
programs writing O_APPEND simultaneously,
in which case you are asking for trouble.
yep. The code in nfs clients to support O_AP
On Dec 18, 2008, at 3:57 PM, Russ Cox wrote:
I would just seek to the end.
Got it. In that case, is there any reason the current version
of 9pfuse doesn't just skip O_APPEND (like it does with
O_LARGEFILE, etc.)? Since 9pfuse revalidate i_size
before writes that's the best one can do anyway(*)
On Thu, Dec 18, 2008 at 3:57 PM, Russ Cox wrote:
> I would just seek to the end.
> That's fine unless you have multiple
> programs writing O_APPEND simultaneously,
> in which case you are asking for trouble.
>
yep. The code in nfs clients to support O_APPEND is a wonder to
behold. A nicer combina
I would just seek to the end.
That's fine unless you have multiple
programs writing O_APPEND simultaneously,
in which case you are asking for trouble.
Russ
32 matches
Mail list logo
