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
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 for
On Sun, Dec 21, 2008 at 2:45 PM, erik quanstrom quans...@quanstro.net 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
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
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 look
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
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 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 think
On Fri, Dec 19, 2008 at 11:21 AM, Anthony Sorace 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
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
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 8:44 AM, ron minnich wrote:
On Thu, Dec 18, 2008 at 7:59 PM, Roman Shaposhnik r...@sun.com wrote:
On Dec 18, 2008, at 7:26 PM, ron minnich wrote:
On Thu, Dec 18, 2008 at 7:06 PM, Roman Shaposhnik r...@sun.com
wrote:
Its fun, yes. But I believe this is more of a
On Fri, Dec 19, 2008 at 11:49 AM, Roman Shaposhnik r...@sun.com 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
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
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 (sizeiounit)
a bunch of simultaneous appends and rewrites of existing blocks
would work perfectly
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).
On Fri, Dec 19, 2008 at 1:32 PM, Charles Forsyth fors...@terzarima.net 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
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
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
On Thu, Dec 18, 2008 at 3:57 PM, Russ Cox r...@swtch.com 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
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 Dec 18, 2008, at 4:03 PM, ron minnich wrote:
On Thu, Dec 18, 2008 at 3:57 PM, Russ Cox r...@swtch.com 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
22 matches
Mail list logo
