On Fri, Mar 17, 2000 at 11:19:03PM +0300, Hans Reiser wrote:
> Steve Dodd wrote:
> >
> > On Thu, Mar 16, 2000 at 12:31:00PM +0100, Olaf Kirch wrote:
> >
> > [..]
> > > 1. There are various standards out there that very much like
> > > "inode numbers" to be unique. Tools like tar will barf badly
> > > if they're not. Whether they're supposed to be stable is a
> > > different issue. Whether they are supposed to be just
> > > 32 bit is also an entirely different issue.
> >
> > 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. Unfortunately glibc.info says ino_t has to be an arithmetic
> > type, so I can't see a way to do such a thing without extending the API. We
> > might even be able to satisfy the open-by-inode people with something like
> > this - or are there other problems with that?
>
> This is more than I have dared to ask for, but I would certainly love to see it.
>
> It is the right thing, in my opinion.
LFS has 64bit ino_t for user space, variable length keys for user space
are rather unlikely (because that would be moving away from Posix). Even
the 64bit ino_t must have a clean fallback to 32bit ino_t because
of binary compatibility for user programs.
There is no interface ATM between kernel and glibc for the 64bit inos
as far as I can see (kernel stat64 still uses 32 bit ino_t), but it is
part of the glibc 2.1 user space stat64 so it would be possible to
use it by only changing glibc (and making sure the applications are
compiled for LFS)
Also having reiserfs-next generation only supporting NFSv3 would be very
unfortunate IMHO -- there are still *lots* of NFSv2 only clients out there
(e.g. nearly all Linux boxes)
-Andi
-
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:24 EST