From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 19 Dec 2008 11:59:19 -0800 From: Roman Shaposhnik In-reply-to: <13426df10812190844p2f10c4afr85147e1f0a41a723@mail.gmail.com> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-id: <7D9A9653-9E39-4FCD-8947-84A18744F80F@sun.com> MIME-version: 1.0 Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: <59EE20C6-0043-4517-ADDA-4BC5C4D24D74@sun.com> <13426df10812181603l56910094m7165f27179047a3a@mail.gmail.com> <8FC3CE71-0E96-4A7E-82E3-0A32722F0EFD@sun.com> <13426df10812181926w7ef1d03bj2ad1befce75b3dc8@mail.gmail.com> <13426df10812190844p2f10c4afr85147e1f0a41a723@mail.gmail.com> Subject: Re: [9fans] 9pfuse and O_APPEND Topicbox-Message-UUID: 6a85ab46-ead4-11e9-9d60-3106f5b1d025 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 >>>> 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. >> > > you want to write at EOF. Where is EOF? On Plan 9 on an append file, > server by definition always knows: it's where the last write was. So > writes go at EOF. 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 -- just open that very same Qid one more time and have a Fid that does honor offsets in your writes. Once again -- I don't deny that ALSO having ALWAYS append files is extremely useful. All I'm saying is that from where I sit the idea of ALSO having a way to make append-only Fids seems to be extremely useful in its own right. And nobody yet cared to give a concrete explanation of why it might be a bad idea. > The 'client write at EOF' is bad for precisely the same reason that > you don't want to use shared memory for locks in a CC-NUMA machine; > you want to send the operation to the data, not move the data to the > operation. Lots of great papers on this over the years ... That is exactly what I'm suggesting -- have yet another mechanism to let the server decide where the EOF is. Thanks, Roman. P.S. Am I that incomprehensible? :-(