>
>
> On Sat, 16 Jan 1999, Alexander Viro wrote:
> >
> > OK, then. We *have* to keep i_ino unique - icache will get royally
> > confused otherwise, but we can easily guarantee uniqueness. Not a BFD. But
> > it will mean that stat() on the same name will give different i_ino each
> > time it is called. It may screw nfsd.
>
> No, "i_ino" does _not_ have to be unique.
>
> Yes, the icache will get confused _if_ the filesystem uses the inode
> hashes. But a filesystem doesn't actually have to use the hashes at all:
> you can get inodes with "get_empty_filp()", and just fill them in into the
> dentry: they don't have to be cached.
Dirty inodes treatment ;-/ So they'ld better *be* cached, but they
can be stored in a separate list.
> Background: the inode hashes are really only for filesystems that
> internally use "iget()" - which is just another helper routine that is
[snip <AOL></AOL> (see another posting - I also want to exterminate iget()
in FAT-*)]
OK, fine with me - we'll always be able to enforce uniqueness later. Not
that hard to do it from the very beginning, but if you are fine without
it... I'ld simply use inode->i_ino = (ino_t)inode, but it will break on
64-bit architectures. BTW, inodes are allocated from one cache. If
slab code provides something like in-cache ID... I didn't read through
mm/slab.c yet, so it's a wild speculation, indeed.
> > Linus, I'm afraid that we'll break nfsd that way. OTOH if somebody
> > exports FAT filesystem via NFS...
>
> knfsd would actually get this right, because it uses dentries.
It's unfsd that makes me worry...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/