xfs
[Top] [All Lists]

Re: Work Items

To: Stephen Lord <lord@xxxxxxx>
Subject: Re: Work Items
From: Andi Kleen <ak@xxxxxxx>
Date: Sat, 12 Oct 2002 23:57:27 +0200
Cc: Alp ATICI <atici@xxxxxxxxxxxxxxxxxxxxx>, Christoph Hellwig <hch@xxxxxxxxxxxxx>, linux-xfs@xxxxxxxxxxx
In-reply-to: <1034455355.1033.4.camel@laptop.americas.sgi.com>
References: <Pine.LNX.4.44.0210121124180.26350-100000@cpw.math.columbia.edu> <1034455355.1033.4.camel@laptop.americas.sgi.com>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.3.22.1i
On Sat, Oct 12, 2002 at 03:42:33PM -0500, Steve Lord wrote:
> The 2 Tbyte limit and 32 bit inodes are totally different things.
> The 32 bit inode number issue can be solved internally within
> the kernel, until you get to system calls, and a number of system
> calls want to make an inode number available to user space. Right
> now there is no room in the structures returned from these calls
> for 64 bits of inode space.


Actually there is. stat64 has enough space for it and glibc supports 
it too. Just the current i386 kernel zeroes the upper 32bits because internally
on 32bit systems ino_t is only defined as long (=32bit.

On 64bit platforms like x86-64 or ia64 it should work fine because ino_t
is 64bit then


asm-i386/posix_types.h

typedef unsigned long     __kernel_ino_t;

asm-i386/stat.h:

struct stat64 {
        ...
    unsigned long long      st_ino;


-Andi



<Prev in Thread] Current Thread [Next in Thread>