Messages in this thread | | | Date | Sun, 17 Jan 1999 15:09:25 -0500 (EST) | From | Alexander Viro <> | Subject | Re: How about we just let all inode numbers on FAT be zero? |
| |
On Sun, 17 Jan 1999, Linus Torvalds wrote:
> > > 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/
| |