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 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? :-(
