From: Al Viro <viro@ftp.linux.org.uk>
To: David Howells <dhowells@redhat.com>
Cc: torvalds@osdl.org, akpm@osdl.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [RHEL5 PATCH 2/4] VFS: Make inode numbers 64-bits
Date: Tue, 15 Aug 2006 02:31:14 +0100 [thread overview]
Message-ID: <20060815013114.GS29920@ftp.linux.org.uk> (raw)
In-Reply-To: <20060814211509.27190.51352.stgit@warthog.cambridge.redhat.com>
On Mon, Aug 14, 2006 at 10:15:09PM +0100, David Howells wrote:
> Make the in-kernel representations of inode number 64-bit in size at a minimum
> as some network filesystems (eg: NFS) and local filesystems (eg: XFS) provide
> such.
>
> The 64-bit inode number will be returned through stat64() and getdents64() on
> archs that are currently set up to do so.
>
> This patch changes __kernel_ino_t to be "unsigned long long" on all archs, but
> changes usages of that in struct stat to be the old type so that the userspace
> interface does not change. The 64-bit division patch is required to get this
> to link on some archs.
>
> struct inode::i_ino and struct kstat::ino have been converted to ino_t.
> Neither needs moving within the bounds of its parent structure to make sure
> that they reside on a 64-bit boundary if the structure itself does so.
NAK. There's no need to touch i_ino and a lot of reasons for not doing
that. ->getattr() can fill 64bit field just fine without that and there's
zero need to touch every fs out there *and* add cycles on icache lookups.
WTF for?
Filesystems that want 64bit values in st_ino are welcome to
* set it in ->getattr() and
* use iget5()
Less PITA for everyone and less intrusive patch that way.
next prev parent reply other threads:[~2006-08-15 1:31 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-14 21:15 [PATCH 0/4] Use 64-bit inode numbers internally in the kernel David Howells
2006-08-14 21:15 ` [RHEL5 PATCH 1/4] Provide fallback full 64-bit divide/modulus ops for gcc David Howells
2006-08-15 6:44 ` Jan Engelhardt
2006-08-15 8:10 ` Andi Kleen
2006-08-15 8:29 ` David Howells
2006-08-18 8:39 ` Pavel Machek
2006-08-18 10:33 ` David Howells
2006-08-14 21:15 ` [RHEL5 PATCH 2/4] VFS: Make inode numbers 64-bits David Howells
2006-08-15 1:31 ` Al Viro [this message]
2006-08-15 8:21 ` David Howells
2006-08-15 9:06 ` Al Viro
2006-08-15 8:32 ` David Howells
2006-08-15 9:02 ` Al Viro
2006-08-15 9:25 ` David Howells
2006-08-15 12:45 ` Stephen Rothwell
2006-08-15 6:48 ` Jan Engelhardt
2006-08-14 21:15 ` [RHEL5 PATCH 3/4] VFS: Clear up u-long-long ino_t print format warnings David Howells
2006-08-14 21:15 ` [RHEL5 PATCH 4/4] VFS: Fix 64-bit ino_t warning in CacheFiles facility David Howells
2006-08-15 0:36 ` [PATCH 0/4] Use 64-bit inode numbers internally in the kernel Josh Boyer
2006-08-15 8:21 ` David Howells
2006-08-15 9:13 ` Al Viro
-- strict thread matches above, loose matches on Subject: below --
2006-08-15 6:57 [RHEL5 PATCH 2/4] VFS: Make inode numbers 64-bits Jan Engelhardt
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=20060815013114.GS29920@ftp.linux.org.uk \
--to=viro@ftp.linux.org.uk \
--cc=akpm@osdl.org \
--cc=dhowells@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.