From: Nathan Scott <nathans@sgi.com>
To: linux-ia64@vger.kernel.org
Subject: IA64 ino_t incorrectly sized?
Date: Wed, 17 Sep 2003 07:10:45 +0000 [thread overview]
Message-ID: <marc-linux-ia64-106378281914262@msgid-missing> (raw)
Hi there,
I've been doing some large filesystem testing on XFS, and noticed
that several of our regression tests are failing. One particular
problem area is xfsdump and its use of the getdents64 interface.
I believe I've traced the problem back to the definition of ino_t
(aka __kernel_ino_t) as an unsigned int in the platform-specific
headers, and I suspect this should instead be an unsigned long on
IA64. Here's the rationale:
- all of IA64 userspace (glibc) allows for 64 bit inode numbers;
see /usr/include/bits/types.h in particular, and __ino_t which
is used in the stat and getdents64 syscalls.
- when we come into the kernel via sys_getdents64, we call into
filesystem specific code via fs/readdir.c::vfs_readdir and the
readdir file operation.
- this passes a filldir_t routine into the fs, which the fs uses
to fill in the getdents buffer for each directory entry.
- filldir64 from sys_getdents64 makes use of the linux_dirent64
structure internally (with a u64 d_ino) and is passed an ino_t
as the inode number.
- so, when we fill in each directory entry we're silently chopping
off the high 32 bits of the inode number (casting from the XFS
64 bit inode to the ino_t argument of the filldir routines),
which causes problems for xfsdump as it is looking at the inode
numbers in the getdents buffer returned from the kernel.
- I can see no reason to have this restriction on IA64, because
userspace does allow for 64 bit inode numbers.
Does anyone know why the IA64 platform-specific ino_t definition
is an int and not a long? Patch below fixes this problem for me
but I wonder if there will be side-effects I haven't considered
(i.e. was there a reason for making this 32 bits originally?).
If not, could the IA64 maintainers push this patch around to the
official kernel trees for me? (pretty please)
many thanks.
--
Nathan
--- /usr/tmp/TmpDir.16879-0/linux/include/asm-ia64/posix_types.h_1.1 Wed Sep 17 16:04:09 2003
+++ linux/include/asm-ia64/posix_types.h Wed Sep 17 11:29:30 2003
@@ -11,7 +11,7 @@
*/
typedef unsigned int __kernel_dev_t;
-typedef unsigned int __kernel_ino_t;
+typedef unsigned long __kernel_ino_t;
typedef unsigned int __kernel_mode_t;
typedef unsigned int __kernel_nlink_t;
typedef long __kernel_off_t;
next reply other threads:[~2003-09-17 7:10 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-17 7:10 Nathan Scott [this message]
2003-09-17 14:33 ` IA64 ino_t incorrectly sized? Jes Sorensen
2003-09-17 17:26 ` David Mosberger
2003-09-29 5:52 ` Nathan Scott
2003-10-08 23:51 ` David Mosberger
2003-10-09 1:25 ` Nathan Scott
2003-10-09 1:57 ` David Mosberger
2003-10-09 3:15 ` Nathan Scott
2003-10-09 3:53 ` David Mosberger
2003-10-09 4:55 ` Nathan Scott
2003-10-09 20:46 ` David Mosberger
2003-10-10 2:22 ` Nathan Scott
2003-10-15 1:25 ` Nathan Scott
2003-10-15 1:48 ` Andrew Morton
2003-10-15 4:47 ` David Mosberger
2003-10-15 5:18 ` Andrew Morton
2003-10-15 6:06 ` Nathan Scott
2003-10-15 6:16 ` Nathan Scott
2003-10-15 6:21 ` David Mosberger
2003-10-15 6:28 ` Andrew Morton
2003-10-15 6:34 ` Nathan Scott
2003-10-15 12:42 ` Andi Kleen
2003-10-15 12:54 ` Christoph Hellwig
2003-10-15 13:29 ` Matthew Wilcox
2003-10-15 13:40 ` Christoph Hellwig
2003-10-15 16:32 ` David Mosberger
2003-10-15 16:59 ` David Mosberger
2003-10-15 17:40 ` David Mosberger
2003-10-15 23:40 ` Neil Brown
2003-10-16 1:20 ` David Mosberger
2003-10-16 22:47 ` Nathan Scott
2003-10-17 0:47 ` Neil Brown
2003-10-17 1:56 ` Nathan Scott
2003-10-21 3:37 ` Neil Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-linux-ia64-106378281914262@msgid-missing \
--to=nathans@sgi.com \
--cc=linux-ia64@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox