From: Noveck, Dave (Dave.Noveck@netapp.com)
Date: 12/04/02-09:50:20 AM Z
Message-ID: <C8CF60CFC4D8A74E9945E32CF096548A0709B8@SILVER.nane.netapp.com>
From: "Noveck, Dave" <Dave.Noveck@netapp.com>
Subject: RE: file_id
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:cburnett@us.ibm.com]
Sent: Monday, December 02, 2002 6:24 PM
To: nfsv4-wg@sunroof.eng.sun.com
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 cburnett@us.ibm.com)
Nicolas Williams <Nicolas.Williams@sun.com>
Sent by: owner-nfsv4-wg@sunroof.eng.sun.com
12/02/2002 04:16 PM
To: Neil Brown <neilb@cse.unsw.edu.au>
cc: Jim Rees <rees@umich.edu>, nfsv4-wg@sunroof.eng.sun.com
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
--
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:34 AM Z CST