From: Mike Eisler (mike@eisler.com)
Date: 03/16/01-01:37:29 PM Z
Message-Id: <200103161848.KAA09423@eagle.webpros.com>
Date: Fri, 16 Mar 2001 11:37:29 -0800 (PST)
From: Mike Eisler <mike@eisler.com>
Dave Noveck writes:
> > I'm not sure I've ever had a customer complaint about appends not
> > working.
>
> Alright. We don't have to tell them to stop complaining because
> they know that complaining is useless. A basic protocol problem
> like that cannot be solved in any time frame that a customer
If there was a way to solve this problem in
existing framework that NFS uses, I'd be on the bandwagon.
> cares about. He'll just do something else, besides using NFS,
> I mean.
What will he use besides NFS?
NFS fails to support a long list of esoterica from UNIX local file
access model. Do we really have to or want to fix them all?
Peter Corbett writes:
> If multiple clients are doing appends to a log, which is a perfectly good
^^^^^^^^^^^^^^^^^^^^^
NFS, including NFSv4 is not designed for simultaneous conflicting
access to a common set of files among multiple clients, except when
file locking, record lockimg, or share reservations are used. DEC/DFS
is the only commericial system I know of that provides that feature.
> use of append writes, then it can't possibly be preferable to (fairly
> frequently) corrupt the file, at a minimum destroying a record and worst
> case leaving the file unparsable, than it is to (very occasionally) insert a
> duplicate record. The latter should be a minor problem that could be solved
> at the application level.
You are advocating breaking a feature that works perfecting when in
the situation NFS is designed for, single writer to a file, in favor
of a situation for one that NFS is not designed more.
> If the server's reply cache is blown out, if part of the workload is several
> clients doing write appends to the same file, then its only going to make
> the situation worse if the clients get into a {getattr, verify -> fail}
^^^^^^^^^^^^^^^^^^^^^^^^^
As I wrote earlier, there was probably something wrong with my idea, Dave
N. pointed out what it was, and I regret mentioning it.
> retry loop competing for the same resource with the eof moving underneath
> them. The server could blow up completely under that load. Again, the
> possibility of an occasional duplicate record seems preferable.
>
> The file might get corrupted "only if write sharing is going on", but isn't
> that the most useful canonical case of append writes?
I think if people really want atomic APPEND, they should probably
look to different solution than NFS.
-mre
This archive was generated by hypermail 2.1.2 : 03/04/05-01:48:41 AM Z CST