Subject: Re: file_id

From: Carl Burnett <[email-masked]>
Date: Mon, 2 Dec 2002 17:23:34 -0600

The client solutions don't look that promising. st_ino is "burned" into 
lots of applications, and they should not have to change because of NFS 
V4. People will just continue to use v2/v3. The server has much more 
flexibility to  generate this value within reasonable POSIX constraints. 
Perhaps fileid should be a mandatory attribute. There is still the 32 bit 
overflow potential for clients with 32 bit ino_t spaces, but that's a more 
manageable issue than having to make one up.

What server implementations do NOT plan to support the fileid attribute?

Carl

Carl Burnett
AIX Kernel Architecture - Distributed File Systems
(512) 838-8498, TL 678-8498
(please reply to [email-masked])

Nicolas Williams <[email-masked]>
Sent by: [email-masked]
12/02/2002 04:16 PM

        To:     Neil Brown <[email-masked]>
        cc:     Jim Rees <[email-masked]>, [email-masked]
        Subject:        Re: file_id

On Tue, Dec 03, 2002 at 09:00:43AM +1100, Neil Brown wrote:
> 2/ st_ino = hash(fileid)   if available
>    st_ino = hash(filehandle) otherwise
> 
>    Would work a lot of the time, but failures are possible and
>    unpredictable.  Personally, I would recommend against it.

The client could also maintain mappings of filehandle->locally generated
inode number; the table would have to drop entries on an LRU basis or
risk growing too large, but table entries would really only be necessary
for files with link count > 1.  This works as long as files with
multiple hard links are rare in a given filesystem.

Nico
--