Subject: Re: file_id

From: "Talpey, Thomas" <[email-masked]>
Date: Wed, 04 Dec 2002 15:30:01 -0500

I believe the historical example of such a server was the
Symbolics Lisp machine implementation. But a more likely
example is a user space server.

Tom.

At 12:49 PM 12/3/2002, Jim Rees wrote:
>When I pushed for adding a unique file identifier to the protocol, I was
>told there were some servers that would be unable to provide this,
>because
>all they have is the file name.  These servers hash the name to get the
>file
>handle.  If the file is renamed, the handle becomes stale, and the
>client
>must re-open.
>
>I don't know which servers these would be, but I would guess they come
>from
>Microsoft.

---

From: Peter Astrand <[email-masked]>
Date: Wed, 4 Dec 2002 23:58:56 +0100 (CET)

> example is a user space server.

I've never understood why user space servers has this problem. I know that 
"unfsd" for example are using all kinds of tricks to generate FHs, but why 
not just use st_dev, st_ino from stat()?

/Peter

---

From: Mike Eisler <[email-masked]>
Date: Wed, 04 Dec 2002 15:48:50 -0800

>not just use st_dev, st_ino from stat()?

On operating environments (OEs) that support fileids,
the ideal file handle for a server running on such an OE was
one that includes a fileid. When the server gets
a request using a file handle it gave out, it needs
an API to map the fileid back to the file. In UNIX kernels
this is trivially provided by a routine originally
called "iget" which took a fileid and device number and returned
a pointer to an in core inode.

The equivalent API is usually not available to user level processes.

Volatile filehandles make user-space NFS servers easier to implement.

Another example is the kernel-based UNIX server that
infrequently serves up FAT filesystems stored on removable
media (if it were fixed media, it wouldn't be infrequent).
Since it's infrequent, it's not worth the implementation
cost of keeping the mappings from file handle to
pathname in stable storage. So with enough files
(likely with cd-roms or zip disks), the entries in the
mapping table get LRUed out and so spurious stale
file handle errors result. With volatile file handles, the
burden of  maintaining more persistant mappings falls
to the client.

    -mre

---

From: Eric Werme USG <[email-masked]>
Date: Thu, 05 Dec 2002 09:46:24 -0500

Mike Eisler wrote:
   
   >not just use st_dev, st_ino from stat()?

To keep file handles unique and catch st_ino reuse, kernels can readily
include a generation number if the physical FS supports it.  If that isn't
available to user level code, they'll miss inode reuse triggered by other
processes on the server and may struggle to track file deletions/creations
done via NFS.

Clients can get especially annoyed if a file handle that used to refer
to a regular file suddenly changes into a directory.  They much prefer
ESTALE.

Except in systems that still have ancient lock daemons.  Those need
to open the file handle to set and remove locks.

	-Ric