From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Howells Subject: [PATCH 0/2] Use 64-bit inode numbers internally in the kernel [try #2] Date: Tue, 15 Aug 2006 16:26:27 +0100 Message-ID: <20060815152627.29222.71414.stgit@warthog.cambridge.redhat.com> Content-Type: text/plain; charset=utf-8; format=fixed Content-Transfer-Encoding: quoted-printable Cc: linux-fsdevel@vger.kernel.org, dhowells@redhat.com, nfsv4@linux-nfs.org, linux-kernel@vger.kernel.org Return-path: To: torvalds@osdl.org, akpm@osdl.org, trond.myklebust@fys.uio.no, aviro@redhat.com List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: nfsv4-bounces@linux-nfs.org Errors-To: nfsv4-bounces@linux-nfs.org List-Id: linux-fsdevel.vger.kernel.org These patches make the kernel pass 64-bit inode numbers internally when communicating to userspace, even on a 32-bit system. They are required because some filesystems have intrinsic 64-bit inode numbers: NFS3+ and X= FS for example. The 64-bit inode numbers are then propagated to userspace automatically where the arch supports it. Problems have been seen with userspace (eg: ld.so) using the 64-bit inode number returned by stat64() or getdents64() to differentiate files, and f= ailing because the 64-bit inode number space was compressed to 32-bits, and so overlaps occur. There are two patches: (1) Make struct kstat::ino and filldir_t's inode number argument u64 rat= her than ino_t and give an EOVERFLOW if an inode number can't be represe= nted to userspace without shedding the top bits of the number. (2) Make NFS represent 64-bit fileids as 64-bit inode numbers to the VFS rather than compressing them to 32-bits on 32-bit systems. David