From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Viro To: 9fans@cse.psu.edu Subject: Re: [9fans] Plan 9 In-Reply-To: <009601c16617$2f37c6b0$f9b9c6d4@SOMA> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Mon, 5 Nov 2001 12:37:10 -0500 Topicbox-Message-UUID: 14a7dda2-eaca-11e9-9e20-41e7f4b1d025 On Mon, 5 Nov 2001, Boyd Roberts wrote: > Most unix VFS's expect (if not insist) unix like semantics and are > generally a horrible mess. One good thing ULTRIX did was that you ... that being the main reason why I gave up on *BSD. Linux VFS was much cleaner and these days it's actually pretty decent. > could have user mode NFS file-servers. The down side was that NFS You can do the same on a _lot_ of Unices, but most of them suffer from fairly nasty deadlocks around the code handling mmap() over NFS when server runs on the same box. They may be harder or easier to trigger, but if you manage to get the box low on memory and create a situation when the only way to reclaim something is to write out a dirty page and throw it away - expect a trouble (page contents is sent to server, server needs memory to write it out, memory pressure only leads to more requests of the same kind). > was far too limiting. I implemented a version of ftpfs on ULTRIX > when I was at Digital. Without going into NFS protocol problems > the basic lesson is to _never_ implement a file-server protocol > over an unreliable, connectionless transport. CODA is cleaner in that respect - exactly for these reasons. For ftpfs it's downright nice - especially since it has commit-on-close semantics (open creates a copy on local fs and passes it back to kernel, then all IO happens on local fs and only metadata-related requests are passed to server; sync and close tell server to commit the changes; there is a mechanism for handling invalidation). For RPC-style filesystems it's a pure hell, obviously - for that stuff 9P fits much better.