[OpenIndiana-discuss] NFS hidden files

[Richard L. Hamilton]

On Jun 5, 2012, at 4:06 PM, James Carlson wrote:

> Gabriele Bulfon wrote:
>> I understand your point.
>> But, my question is...shouldn't a network filesystem try to completely emulate a local file system,
>> trying to hide as much as possible the fact of being a network share?
> 
> Sure, although "try" is certainly the operative word here.
> 
>> In this case, how does a local filesystem like ZFS or UFS manage these situations?
> 
> A local file system doesn't have this problem, because the directory
> entry is distinct from the "handle" that the program has on an open
> file.  An open local file essentially references the inode for that
> file.  If the directory entry (which points to the inode) is removed,
> the program can keep on using the now-nameless inode without trouble.
> When all references to the inode are dropped, the space is returned to
> the free pool.
> 
> (Depending on the OS, you may even be able to use link(2) to reattach an
> unlinked but still open file by using the procfs nodes.)
> 
> With NFS, the server doesn't know whether files are open or closed.  If
> the client actually removed the file, that would immediately invalidate
> any other client handles, and break the applications still using the
> now-unreferenced file.
> 
> In short, this is just how NFS works.
> 
>> Local file systems do not create .xxx files, and they never show up even in the situations you describe.
> 
> True.  Local file systems aren't remote.  :-/
> 
>> So, why NFS should be different? I believe that the NFS server may hold this files for himself and
>> the processes that already have opened sessions on them, not showing them in folder listings
>> (as zfs can do with its .zfs folder).
> 
> I suppose that NFS clients could be designed to hide these files from
> the user optionally.  It may well make some operations a little (or
> perhaps a lot) strange, but I think it could be made to work.  It's just
> not how it's done today.
> 
>> Also, is it correct by the file system to allow deletion of a file opened by someone else?
> 
> Sure; standard UNIX/POSIX semantics apply.
> 
>> For example, an "rm -r folder" will fail in case I have a bash inside it's tree.
> 
> That's not true.  In one window:
> 
> % bash
> carlsonj at carlson:/build/carlsonj$ mkdir foo
> carlsonj at carlson:/build/carlsonj$ cd foo
> carlsonj at carlson:/build/carlsonj/foo$
> 
> Now, in another window:
> 
> carlsonj at carlson:/build/carlsonj$ rm -r foo
> carlsonj at carlson:/build/carlsonj$
> 
> Now back in the first window:
> 
> carlsonj at carlson:/build/carlsonj/foo$ /bin/pwd
> pwd: cannot determine current directory!
> carlsonj at carlson:/build/carlsonj/foo$
> 
> You can always remove anything you want to remove, assuming you have the
> right permissions.  Directory entries are just that -- directory
> entries.  They have the name of the object and a pointer to where the
> object resides.  They're not the object itself.
> 
>> I believe an option to hide them would do no harm.
> 
> Fortunately, it's an open process.  Read RFCs 1813 and 3010 to start,
> and propose your own design.

A remote filesystem protocol by AT&T (and present only in very early Solaris, as I recall), called RFS, went to great lengths to provide all the usual semantics.  You could even access remote device files (although presumably both client and server had to support the same byte order, word size, alignment, etc, AND ioctls, for ioctls to be packaged up properly to work with remote devices - not sure how that worked!).  In fact, processes on the client and server could communicate with each other through a FIFO on the shared filesystem!

The flip side was that unlike NFS, if the server crashed, the client didn't just wait for the server to come back up, it got an error, not unlike you would if someone unplugged a local disk.  That is, the server was NOT stateless, but had state that was lost in a crash, which left returning an error to the client as the only option.

Compatible, reliable, high-performance: pick two.  (like a number of other "pick two" cases)