In Pine.LNX.4.44.0210161557250.24259-100000_at_kevin-pc.atkinson.dhs.org, Kevin Atkinson <kevin_at_atkinson.dhs.org> wrote:


> Yes others file systems have the same semantics as Coda but most general 
> purpose file systems don't.  With most file systems you can seek anywhere 
> in the file and only read part of it.  Applications should not have to 
> rework the way they work in order to work around limitations of an of an 
> specific file system which does not have the expected behavior of a 
> general purpose file system.

  Actually, I suspect there's a lot of "work-around" in regular
applications that wouldn't be necessary if you changed filesystem
semantics.

  Atomic supercede is a rare filesystem behavior whose absence some
applications have to work around.

  If you subscribe to some of Reiser's rabble-rousing, you could say
that most application data formats are a workaround for the fact that
filesystems don't do an efficient job of storing tiny data chunks.

  The necessity of tape backups is higher than it would normally be if
your filesystem supported copy-on-write snapshots.

  Stop for a minute and realize that the only reason you think Coda is
strange is that you don't realize that the "correctness" of the
semantics you are familiar with is just a consensus hallucination of the
majority mixed with some practicality to keep everyone drinking the same
kool-aid.

> Um that is a lot easier said than done.  Once again this is a workaround 
> due to the limits of the Coda file system which I do not think should be 
> necessary.

  When you optimize for a particular problem, you often reduce the
performance of the system for other problems.  I refer you to RFC1925
section 7a.