Subject: [nfsv4] NFS client copying 64bit fileid's to 32bit inodes generates "value too large" on "ls" command.

From: Steven Huntington <[email-masked]>
Date: Sat, 19 Mar 2005 10:15:46 -0800

We have an internal disagreement of who is responsible to correct this.
Here are the basic positions.

1) To support global namespace the NFSv4 protocol defines the fileid attr
as 64bit,  For proper operation, It is the NFSv4 clients responsibility to
generate a 32bit inode or document the restriction and/or error if copying
the NFSv4 fileid to ino.  If this can not be done, the suggestion is to run
NFSv3 to obtain 32bit values if needed.

2) Worry about global name space later.  Granting access to the largest
number of clients today is key.  The server should only return 32bit values
until the major client platforms support 64bit.

Seems #2 will prevail here.

Cheers,

Steve Huntington, IBM San Jose

Phone:            (408) 256-1948 (T/L 276-1948)
Fax                   (408) 256-2500
Office:              San Jose 50-C398
Internet:          [email-masked]
Lotus Notes: Steven Huntington/San Jose/IBM@IBMUS

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: "Noveck, Dave" <[email-masked]>
Date: Sat, 19 Mar 2005 14:28:02 -0500

> We have an internal disagreement of who is responsible to correct 
> this. Here are the basic positions.

> 1) To support global namespace the NFSv4 protocol defines the fileid 
> attr as 64bit, 

Not true as far as I know.  You can implement a global namespace with 
many fs's (each different fsid) each having less than 4 billion files.
I don't think the 64-bit fileid was motivated by global namespace, but
simply because protocols last a long time, and 32 bits seemed quite
constraining looking forward.

The issue of needing a big fileid space arises with various forms of 
synthesized name space in which multiple fs's are made to look like a
single fs, as well as a single namespace.  That issue is more pressing
for v3, where you don't have the option of creating a new fileid space 
within a namespace via changing the fsid value.

> For proper operation, It is the NFSv4 clients responsibility to generate 
> a 32bit inode or document the restriction and/or error if copying the 
> NFSv4 fileid to ino. If this can not be done, the suggestion is to run 

NFSv3 also has 64-bit fileid fields.

Clients differ in what they do.  Some clients accept fileid's beyond 32 
bits just fine, but, if that file is stat'ed by a application compiled 
for 32 bits, then the stat call gets an error and the application dies.
Users just hate that.   

> 2) Worry about global name space later. Granting access to the 
> largest number of clients today is key. The server should only 
> return 32bit values until the major client platforms support 64bit. 

> Seems #2 will prevail here.

I don't see that 1 and 2 are incompatible.  Servers, as for v3, need
to deal with clients that don't make good efforts to handle fileids 
beyond the 32-bit range and protect 32-bit applications from the consequences.
If your server needs to operate with the largest number of clients, then
you need to return, or be able to return under an option, 32-bit-only
fileids and you probably need to do that not only until the major client 
platforms do better but until clients that do not are very rarely seen,
i.e. you need to do this for a very long while.

As for 1, I think doing better for your users is a good thing .  It is 
an implementation quality issue.  The spec says the fileid is a 64-bit
value but it can't tell you what the consequences for users will be 
with larger values and whether those consequences are acceptable.  That's 
up to you and your users.  As a user my feeling is that it is better 
to compromise on fileid uniqueness when dealing with 32-bit applications,
and give the user something that has some possibility of conflict as opposed
to an error which stops him cold.  Most applications that do stat don't
care about fileid uniqueness.