Re: [9fans] 9pfuse and O_APPEND

[Roman Shaposhnik <rvs@sun.com>]

On Dec 19, 2008, at 8:44 AM, ron minnich wrote:
> On Thu, Dec 18, 2008 at 7:59 PM, Roman Shaposhnik <rvs@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 <rvs@sun.com>
>>> 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? :-(