Subject: Re: file_id

From: Jim Rees <[email-masked]>
Date: Mon, 02 Dec 2002 11:06:36 -0500

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?

---

From: Neil Brown <[email-masked]>
Date: Tue, 3 Dec 2002 09:00:43 +1100

> available and fits in the client's ino_t?

As Dave Noveck says, it is about picking a strategy.
Maybe we should have a list of possibly strategies for providing
st_ino on a 32bit POSIX system that could go in the implementation RFC
if/when that eventuates (or did I miss it?)

1/ st_ino = fileid & ((1<<32)-1);
      only works when fileid_unique_bits <= 32

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.

3/ st_ino = next_free_ino ++;
     /* plus check that this ino is currently in use in the inode
     cache */

   This is essentially what Trond was suggesting when he talked about
   the Linux VFS's mechanism for providing unique inums.

   This works fine for "cp".  Isn't so good for 'cpio' when it using
   dev/ino to detect hard-links to the same file, especially when
   archiving a large filesystem with widely spaced links.

4/ st_ino = 0;

   This deliberately and overtly ignores the API requirement.  This
   has the advantage of making programs that have a dependancy on
   st_ino more obvious so they could then be identified and fixed.

   Ofcourse 'fixing' them is non-trivial.
   One option would be to teach them that a st_ino of 0 means 'This
   might be the same as another file, or it might not, I cannot tell
   you'. 
   Another would be to develop and promote a new API ( maybe
		fnctl(fd1, F_SAMEFILE, fd2)
   ) that allowed an application to check if two filedescriptirs
   referred to the same file - options "0 == yes, 1 == not, 2 ==
   maybe".
   This fcntl would only be required by filesystems that set st_ino
   to 0.

I have a personal preference for 1 with a fallback to 4, simply
because they are both deterministic.

NeilBrown

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 Dec 2002 14:16:02 -0800

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