Subject: RE: file_id

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 4 Dec 2002 07:50:20 -0800

By making it mandatory you are saying that if you have a file
system which can't generate the unique id's, you would rather 
not have it accessible by v4 than have it accessible in an
imperfect manner.  For better or worse, that hasn't been the
V4 philosophy.

I think of file_id as belonging to a class (maybe it's the
only one) of "strongly recommended" attributes.  It's not
mandatory (i.e. you MUST implement it) but you SHOULD and 
only a very good reason suffices to excuse you. 

-----Original Message-----
From: Carl Burnett [mailto:[email-masked]]
Sent: Monday, December 02, 2002 6:24 PM
To: [email-masked]
Subject: Re: file_id

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
--