This is the mail archive of the
libc-alpha@sourceware.cygnus.com
mailing list for the glibc project.
Re: 64 bit inode numbers
- To: Andreas Jaeger <aj at oss dot sgi dot com>
- Subject: Re: 64 bit inode numbers
- From: Phil Schwan <phil at mydonniebarnes dot com>
- Date: Tue, 18 Apr 2000 10:49:52 -0400
- Cc: libc-alpha at sourceware dot cygnus dot com
- References: <20000405163402.H5249@linuxcare.com> <hoem8ezuyk.fsf@awesome.engr.sgi.com>
On Apr 09, Andreas Jaeger wrote:
> Yes! You break binary compatibility. Since you change the overall
> size of the structure and the offsets within, every single program
> that uses the new struct needs to be recompiled - or we need to add
> compatibility code to glibc. You'd better stay with 32bit inodes on
> 32bit systems. To discuss this further, please email to
> libc-alpha@sourceware.cygnus.com.
Well, yes, of course one breaks binary compatibility. I was proposing
the ``add hackery to glibc'' route of accomplishing this, but that
probably wasn't clear.
Since sending the original message, I've discovered that the 64 bit
inode problem doesn't crop up until one crosses the 2TB FS size
boundary, but this doesn't make me uninterested--just less urgently
interested.
Any of the proposed methods of condensing or hashing inode numbers
that XFS returns down to 32 bits will be poor, and will not result in
guaranteed unique inode numbers once applied to a >2TB FS. I suspect
that some others (Reiser, perhaps?) seek 64 bit inodes as well, and
this seems like something that can reasonably be solved in the
not-too-terribly-distant future.
-Phil