Subject: RE: file_id

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 2 Dec 2002 08:32:26 -0800

I think the issue is that while you can see that a given
fileid fits in 32 bits, you can't know that all of them
do.  This allows you to pick a strategy to deal with 
fileid's when you first encounter a filesystem.  If you
want 32-bit unique id's and the server supplies them,
then you don't need to map.  If the first few objects
have id's that fit, then you are going to give these out,
and then when you have to deal with wierd cases with those
that don't map, things get harder.  It's possible to deal
with, but it would be nicer if the server told the client 
what it could do and stuck with it.

By the way, does the spec say that if file-id is available
for some objects, it must be available for all?  I think we
had been assuming that if file-id is available for given fs,
it available for all objects in the fs, and will always be
available for objects in that fs (i.e. that it's not valid
to all of a sudden stop supporting file-id), but I don't see
where the spec actually specifies that.

On area where this gets fuzzy is migration.  I had been 
assuming that file-id's might change on a migration event
involving volatile filehandles.  Another possibility is that
the file-id attribute might all of a sudden become non-supported
on a migration event (or the reverse which is easier to deal
with).  Sounds like a great test for Connectathon xx (for 
xx > 03).  

-----Original Message-----
From: Jim Rees [mailto:[email-masked]]
Sent: Monday, December 02, 2002 11:07 AM
To: [email-masked]
Subject: Re: file_id 

I don't see the point.  The client has to be prepared for
fileid_unique_bits = 64 anyway, and in fact has to be prepared for no fileid
at all.  So why bother doing things differently if the fileid happens to be
available and fits in the client's ino_t?