Messages in this thread | | | From | Steve Dodd <> | Date | Sun, 19 Mar 2000 13:05:24 +0000 | Subject | Re: reiserfs and knfsd and NFSv4 and volatile file handles |
| |
On Fri, Mar 17, 2000 at 11:19:03PM +0300, Hans Reiser wrote: > Steve Dodd wrote:
> > Is there any chance of getting an API for user space that works in terms of > > opaque keys of variable lengths, rather than inode numbers? It's a shame > > something like this wasn't considered by however came up with the stat64, > > etc. set of functions. [..]
> This is more than I have dared to ask for, but I would certainly love to see > it.
Actually, I *think* I'm being bloody stupid. All POSIX needs unique, stable inode numbers -- you can't open-by-inode from user space, and this makes life a lot easier. The filesystem has to ensure that each file *has* a unique, stable inode number for reporting via stat(), but it doesn't have use the thing at all, only maintain it. Internally it can refer to inodes by whatever it wants. The only problem is that you can't support >4g inodes on 32bit systems, but I think an option to keep this limitation or break POSIX (tar, etc.) would be OK -- people who want to use huge numbers of inodes on 32bit systems can't expect tar to work. How the filesystem maintains the inode number is up to it; a bitmap, perhaps. NFS issues depend on the file handle size supported by the version of NFS (or they will when the VFS supports open-by-fh), but are much the same as for userspace.
-- "So how do you feel, having given up on coffee?" "A bit slow, but you have to expect that on a Monday." "It's Thursday."
- 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/
| |