Re: Patch to implement getattr [patch]

Jamie Lokier (lkd@tantalophile.demon.co.uk)
Thu, 15 Jul 1999 01:50:10 +0200


Alexander Viro wrote:
> > > 3. As for inode numbers - look at the stuff in fs/fat/inode.c. You can do
> > > constant inumbers during the life of *open* file.
> >
> > And since FAT has no hard links, as long as inumbers are not reused
> > quickly this gives correct behaviour with cpio, tar, cp etc.
>
> Jamie, look into the file in question. There sits an implementation
> of dual caching. fs may use its own key (of arbitrary size - icache
> doesn't care) and completely avoid iget(). Not messing with icache
> behaviour.

> > It isn't so correct with filesystems that have hard links.

Hi Alex,

I was referring to your statement "constant inumbers during the life of
an *open* file" -- it suggests the inumbers may change when the file is
not open.

cpio, tar, cp etc. use stat() to check inumbers to find hard links. Of
course if inumbers change then they won't find the hard links.

If your implementation provides stronger guarantees then great.

> Yes, it is. Internally FAT uses the directory entry location as the key.
> Glue in fs/fat/inode.c allows icache to keep constant i_ino and have its
> way wrt purging, etc. IIRC I've posted a description of this stuff on
> linux-fsdevel back in April or May. Look through archives - fsdevel is not
> too noisy.

Isn't there problem that if the file is renamed, then leaves the kernel
cache, and is brought back by a later stat(), it gets a different ino?
Thus breaking hard link detection, but nothing else.

- Jamie

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