Subject: RE: append writes (con't)

From: Mike Eisler <[email-masked]>
Date: Fri, 16 Mar 2001 11:37:29 -0800 (PST)

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

---

From: Eric Werme USG <[email-masked]>
Date: Mon, 19 Mar 2001 10:54:27 -0500

While I think append writes may deserve be outside of exotica,  I think
making NFS handle all known exotica (and some we can conjure up) is a
mistake.  I don't think we can please all of the people all of the time.

For special purpose applications with serious exotica, say databases, while
it may be easy/helpful/adequate for a first pass to use NFS, ultimately
such applications need to define their own protocol tuned to the application
at hand.  Even the multiple clients writing to a single log file situtation
can benefit from its own protocol where the client can pretty reliably
come up with a unique timestamp and the server can discard ancient requests
and check its own cache for duplicates (and can look for important data
to notify sysadmins, transfer resources, initiate shutdowns, etc.)

My point is that if we handle lots of exoticas, various applications are
likely to implement their own protocols anyway to handle exotica that
lies outside of the file system.

In the case of the log file,  why not just use file locking?  After all,
that's what it's there for!  Besides, updating log files is ordinarily
not a high badwidth activity.  One downside is that if a site is experiencing
major problems, one client may grab the lock but crash before it can
release it.  Meanwhile several other clients may enter similar death throes
and can't shut themselves down cleanly.  This use of append writes is getting
into exotica.  On the bright side, unlocked writes won't get executed
twice when the client dies right after getting out the write request.

	-Ric Werme