From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 24 Dec 2008 22:04:53 -0800 From: Roman Shaposhnik In-reply-to: <42fe5d2488144155692f859a62a64b07@quanstro.net> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-id: <5B0D7CF9-2F33-45B1-B445-6A4EDFBF8BEE@sun.com> MIME-version: 1.0 Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: <42fe5d2488144155692f859a62a64b07@quanstro.net> Subject: Re: [9fans] 9pfuse and O_APPEND Topicbox-Message-UUID: 6f9dd5a4-ead4-11e9-9d60-3106f5b1d025 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.