Messages in this thread | | | Date | Thu, 15 Jul 1999 01:50:10 +0200 | From | Jamie Lokier <> | Subject | Re: Patch to implement getattr [patch] |
| |
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/
| |