On Wednesday 02 March 2005 10:13, Trond Myklebust wrote: > on den 02.03.2005 Klokka 09:18 (+0100) skreiv Andi Kleen: > > On Wed, Mar 02, 2005 at 12:46:23AM +0100, Andreas Schwab wrote: > > > Bernd Schubert <[EMAIL PROTECTED]> writes: > > > > Hmm, after compiling with -D_FILE_OFFSET_BITS=64 it works fine. But > > > > why does it work without this option on a 32bit kernel, but not on a > > > > 64bit kernel? > > > > > > See nfs_fileid_to_ino_t for why the inode number is different between > > > 32bit and 64bit kernels. > > > > Ok that explains it. Thanks.
Many thanks also from me! > > > > Best would be probably to just do the shift unconditionally on 64bit > > kernels too. > > > > Trond, what do you think? > > Why would this be more appropriate than defining __kernel_ino_t on the > x86_64 platform to be of the size that you actually want the kernel to > support? > > I can see no good reason for truncating inode number values on platforms > that actually do support 64-bit inode numbers, but I can see several Well, at least we would have a reason ;) > reasons why you might want not to (utilities that need to detect hard > linked files for instance). Anyway, glibc already seems to have a condition for that, so IMHO glibc also could truncate the inode numbers if needed. And finally glibc probably knows best if its compiled as 32bit or 64bit. Will take a look into the glibc sources. Many, many thanks to all for their help! Best wishes, Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
