>
>
> On Sat, 16 Jan 1999, Colin Plumb wrote:
> >
> > And you know, maybe that *is* the right answer. Just teach the backup
> > software that inode number zero means there are no hard links and
> > the kernel's tired of lying to it.
>
> I'd prefer for inode numbers to be completely made up, possibly by just
> doing
>
> static u32 msdos_ino = 0;
> #define get_vfat_ino() (++msdos_ino)
>
> The inode number doesn't have to be unique, but the above makes at least a
> small attempt to make sure that under normal circumstances you can never
> see any inode numbers that are the same.
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.
Anyway, I'm going to add inode_get_unique() to fs/inode.c,
move the location info for FAT into the msdos_inode_info, exterminate
iget() from msdos/vfat/umsdos (it will break after such change and it
seems to me that it was never intended to be used in ways it's used
there). Stuff around readdir() will have to to use dentry lookups - we'll
be unable to locate struct inode by directory entry anymore. BTW, we'll
have to drop inode from icache as soon as i_count goes to zero (doable).
> Note that things like "getcwd()" depend on inode numbers, until everybody
> has upgraded to the (currently nonexistent) library that uses the getcwd()
> system call. So returning 0 is not an option, but returning a pseudo-
> random number that is only stable for as long as an inode is in use _is_
> an option (ie the silly 32-bit counter).
Linus, I'm afraid that we'll break nfsd that way. OTOH if somebody
exports FAT filesystem via NFS...
Al
-
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/