(Illustration by Gaich Muramatsu)
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.Received on 2002-10-16 16:29:53