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/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:26 EST