* Re: [RFC 0/3] Convert XFS inode hashes to radix trees [not found] <20061003060610.GV3024@melbourne.sgi.com> @ 2006-10-03 21:23 ` Chris Wedgwood 2006-10-03 22:22 ` David Chinner [not found] ` <20061003222256.GW4695059__33273.3314754025$1159914338$gmane$org@melbourne.sgi.com> 0 siblings, 2 replies; 7+ messages in thread From: Chris Wedgwood @ 2006-10-03 21:23 UTC (permalink / raw) To: David Chinner; +Cc: xfs-dev, xfs, dhowells, LKML On Tue, Oct 03, 2006 at 04:06:10PM +1000, David Chinner wrote: > Overall, the patchset removes more than 200 lines of code from the > xfs inode caching and lookup code and provides more consistent > scalability for large numbers of cached inodes. The only down side > is that it limits us to 32 bit inode numbers of 32 bit platforms due > to the way the radix tree uses unsigned longs for it's indexes commit afefdbb28a0a2af689926c30b94a14aea6036719 tree 6ee500575cac928cd90045bcf5b691cf2b8daa09 parent 1d32849b14bc8792e6f35ab27dd990d74b16126c author David Howells <dhowells@redhat.com> 1159863226 -0700 committer Linus Torvalds <torvalds@g5.osdl.org> 1159887820 -0700 [PATCH] VFS: Make filldir_t and struct kstat deal in 64-bit inode numbers 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 XFS for example. The 64-bit inode numbers are then propagated to userspace automatically where the arch supports it. [...] Doing this will mean XFS won't be able to support 32-bit inodes on 32-bit platforms the above (merged) patch --- though given that cheap 64-bit systems are now abundant does anyone really care? ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC 0/3] Convert XFS inode hashes to radix trees 2006-10-03 21:23 ` [RFC 0/3] Convert XFS inode hashes to radix trees Chris Wedgwood @ 2006-10-03 22:22 ` David Chinner 2006-10-04 0:47 ` Chris Wedgwood ` (2 more replies) [not found] ` <20061003222256.GW4695059__33273.3314754025$1159914338$gmane$org@melbourne.sgi.com> 1 sibling, 3 replies; 7+ messages in thread From: David Chinner @ 2006-10-03 22:22 UTC (permalink / raw) To: Chris Wedgwood; +Cc: David Chinner, xfs-dev, xfs, dhowells, LKML On Tue, Oct 03, 2006 at 02:23:35PM -0700, Chris Wedgwood wrote: > On Tue, Oct 03, 2006 at 04:06:10PM +1000, David Chinner wrote: > > Overall, the patchset removes more than 200 lines of code from the > > xfs inode caching and lookup code and provides more consistent > > scalability for large numbers of cached inodes. The only down side > > is that it limits us to 32 bit inode numbers of 32 bit platforms due > > to the way the radix tree uses unsigned longs for it's indexes > > commit afefdbb28a0a2af689926c30b94a14aea6036719 > tree 6ee500575cac928cd90045bcf5b691cf2b8daa09 > parent 1d32849b14bc8792e6f35ab27dd990d74b16126c > author David Howells <dhowells@redhat.com> 1159863226 -0700 > committer Linus Torvalds <torvalds@g5.osdl.org> 1159887820 -0700 > > [PATCH] VFS: Make filldir_t and struct kstat deal in 64-bit inode numbers > > 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 XFS > for example. The 64-bit inode numbers are then propagated to userspace > automatically where the arch supports it. > [...] > > Doing this will mean XFS won't be able to support 32-bit inodes on > 32-bit platforms the above (merged) patch --- though given that cheap > 64-bit systems are now abundant does anyone really care? That's a good question. In a recent thread on linux-fsdevel about these patches Christoph Hellwig pointed out that 32bit user space is not ready for 64 bit inodes, so it's probably going to be a while before the second half of this mod is ready (which exports 64 bit inodes ito userspace on 32bit platforms). http://marc.theaimsgroup.com/?l=linux-fsdevel&m=115946211808497&w=2 http://marc.theaimsgroup.com/?l=linux-fsdevel&m=115948836023569&w=2 ISTR someone else also menitoning that 64bit inodes on 32-bit machines also breaks the dynamic linker, but I can't find a reference to that atm. As it stands, there's still a few barriers to getting 64 bit inodes on 32 bit platforms and I can't see them going away quickly. Right now I see little reason in moving to 64 bit inodes for 32 bit platforms for XFS because of the 16TB filesystem size limit (that only needs 33-36 bit inodes depending on the inode size) and no 32bit platform is currently able to repair a filesystem of that size. And yes, 64 bit systems are cheap, cheap, cheap so IMO this functionality is really irrelevant moving forward. If it had come along a couple of years ago then it would be different, but I think mainstream technology is finally catching up with XFS so it's not a critical issue anymore... ;) Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC 0/3] Convert XFS inode hashes to radix trees 2006-10-03 22:22 ` David Chinner @ 2006-10-04 0:47 ` Chris Wedgwood 2006-10-04 1:43 ` David Chinner 2006-10-04 19:22 ` Trond Myklebust 2 siblings, 0 replies; 7+ messages in thread From: Chris Wedgwood @ 2006-10-04 0:47 UTC (permalink / raw) To: David Chinner; +Cc: xfs-dev, xfs, dhowells, LKML On Wed, Oct 04, 2006 at 08:22:56AM +1000, David Chinner wrote: > That's a good question. In a recent thread on linux-fsdevel about > these patches Christoph Hellwig pointed out that 32bit user space is > not ready for 64 bit inodes, so it's probably going to be a while > before the second half of this mod is ready (which exports 64 bit > inodes ito userspace on 32bit platforms). yes a patch changing struct kstat and filldir* was merged... > http://marc.theaimsgroup.com/?l=linux-fsdevel&m=115946211808497&w=2 > http://marc.theaimsgroup.com/?l=linux-fsdevel&m=115948836023569&w=2 > As it stands, there's still a few barriers to getting 64 bit inodes > on 32 bit platforms and I can't see them going away quickly. Right > now I see little reason in moving to 64 bit inodes for 32 bit > platforms for XFS because of the 16TB filesystem size limit (that > only needs 33-36 bit inodes depending on the inode size) and no > 32bit platform is currently able to repair a filesystem of that > size. so that leaves NFS3+ is it really worth the pain then? ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC 0/3] Convert XFS inode hashes to radix trees 2006-10-03 22:22 ` David Chinner 2006-10-04 0:47 ` Chris Wedgwood @ 2006-10-04 1:43 ` David Chinner 2006-10-04 19:22 ` Trond Myklebust 2 siblings, 0 replies; 7+ messages in thread From: David Chinner @ 2006-10-04 1:43 UTC (permalink / raw) To: David Chinner; +Cc: Chris Wedgwood, xfs-dev, xfs, dhowells, LKML On Wed, Oct 04, 2006 at 08:22:56AM +1000, David Chinner wrote: > On Tue, Oct 03, 2006 at 02:23:35PM -0700, Chris Wedgwood wrote: > > On Tue, Oct 03, 2006 at 04:06:10PM +1000, David Chinner wrote: > > > Overall, the patchset removes more than 200 lines of code from the > > > xfs inode caching and lookup code and provides more consistent > > > scalability for large numbers of cached inodes. The only down side > > > is that it limits us to 32 bit inode numbers of 32 bit platforms due > > > to the way the radix tree uses unsigned longs for it's indexes > > > > commit afefdbb28a0a2af689926c30b94a14aea6036719 > > tree 6ee500575cac928cd90045bcf5b691cf2b8daa09 > > parent 1d32849b14bc8792e6f35ab27dd990d74b16126c > > author David Howells <dhowells@redhat.com> 1159863226 -0700 > > committer Linus Torvalds <torvalds@g5.osdl.org> 1159887820 -0700 > > > > [PATCH] VFS: Make filldir_t and struct kstat deal in 64-bit inode numbers > > > > 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 XFS > > for example. The 64-bit inode numbers are then propagated to userspace > > automatically where the arch supports it. > > [...] > > > > Doing this will mean XFS won't be able to support 32-bit inodes on > > 32-bit platforms the above (merged) patch --- though given that cheap > > 64-bit systems are now abundant does anyone really care? > > That's a good question. In a recent thread on linux-fsdevel about > these patches Christoph Hellwig pointed out that 32bit user space is > not ready for 64 bit inodes, so it's probably going to be a while > before the second half of this mod is ready (which exports 64 bit > inodes ito userspace on 32bit platforms). Ahhh.... I think I misread what Chris wrote here - _32_ bit inodes on 32 bit platforms not working? I can't see how this would be the case with the mods I posted given that they are entirely internal to XFS and don't change any external inode number interfaces. And the above commit shouldn't break XFS either. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC 0/3] Convert XFS inode hashes to radix trees 2006-10-03 22:22 ` David Chinner 2006-10-04 0:47 ` Chris Wedgwood 2006-10-04 1:43 ` David Chinner @ 2006-10-04 19:22 ` Trond Myklebust 2 siblings, 0 replies; 7+ messages in thread From: Trond Myklebust @ 2006-10-04 19:22 UTC (permalink / raw) To: David Chinner; +Cc: Chris Wedgwood, xfs-dev, xfs, dhowells, LKML On Wed, 2006-10-04 at 08:22 +1000, David Chinner wrote: > On Tue, Oct 03, 2006 at 02:23:35PM -0700, Chris Wedgwood wrote: > > On Tue, Oct 03, 2006 at 04:06:10PM +1000, David Chinner wrote: > > > Overall, the patchset removes more than 200 lines of code from the > > > xfs inode caching and lookup code and provides more consistent > > > scalability for large numbers of cached inodes. The only down side > > > is that it limits us to 32 bit inode numbers of 32 bit platforms due > > > to the way the radix tree uses unsigned longs for it's indexes > > > > commit afefdbb28a0a2af689926c30b94a14aea6036719 > > tree 6ee500575cac928cd90045bcf5b691cf2b8daa09 > > parent 1d32849b14bc8792e6f35ab27dd990d74b16126c > > author David Howells <dhowells@redhat.com> 1159863226 -0700 > > committer Linus Torvalds <torvalds@g5.osdl.org> 1159887820 -0700 > > > > [PATCH] VFS: Make filldir_t and struct kstat deal in 64-bit inode numbers > > > > 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 XFS > > for example. The 64-bit inode numbers are then propagated to userspace > > automatically where the arch supports it. > > [...] > > > > Doing this will mean XFS won't be able to support 32-bit inodes on > > 32-bit platforms the above (merged) patch --- though given that cheap > > 64-bit systems are now abundant does anyone really care? Which completely ignored the fact that NFS systems are already having to truncate 64-bit inode numbers to 32-bits and pass these truncated values up to userspace. Collisions have been observed in the wild, and I've already had to change the 64-bit->32-bit hashing algorithm on at least one occasion. By moving that truncation into userspace, we will at least give 64-bit standards-compliant programs a chance to work correctly. Trond ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <20061003222256.GW4695059__33273.3314754025$1159914338$gmane$org@melbourne.sgi.com>]
* Re: [RFC 0/3] Convert XFS inode hashes to radix trees [not found] ` <20061003222256.GW4695059__33273.3314754025$1159914338$gmane$org@melbourne.sgi.com> @ 2006-10-04 17:59 ` Andi Kleen 2006-10-05 0:37 ` David Chinner 0 siblings, 1 reply; 7+ messages in thread From: Andi Kleen @ 2006-10-04 17:59 UTC (permalink / raw) To: David Chinner; +Cc: xfs-dev, xfs, dhowells, LKML David Chinner <dgc@sgi.com> writes: > > And yes, 64 bit systems are cheap, cheap, cheap so IMO this > functionality is really irrelevant moving forward. If it had come > along a couple of years ago then it would be different, but I think > mainstream technology is finally catching up with XFS so it's not a > critical issue anymore... ;) One issue is that people often still run a lot of 32bit userland even with 64bit kernels. The compat layer will just truncate the inodes I think. But so far I haven't heard of anybody complaining on x86-64. -Andi ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC 0/3] Convert XFS inode hashes to radix trees 2006-10-04 17:59 ` Andi Kleen @ 2006-10-05 0:37 ` David Chinner 0 siblings, 0 replies; 7+ messages in thread From: David Chinner @ 2006-10-05 0:37 UTC (permalink / raw) To: Andi Kleen; +Cc: David Chinner, xfs-dev, xfs, dhowells, LKML On Wed, Oct 04, 2006 at 07:59:15PM +0200, Andi Kleen wrote: > David Chinner <dgc@sgi.com> writes: > > > > And yes, 64 bit systems are cheap, cheap, cheap so IMO this > > functionality is really irrelevant moving forward. If it had come > > along a couple of years ago then it would be different, but I think > > mainstream technology is finally catching up with XFS so it's not a > > critical issue anymore... ;) > > One issue is that people often still run a lot of 32bit userland > even with 64bit kernels. Which is one of the reasons why XFS uses 32 bit inodes by default even on 64 bit kernels. XFS does not use 64 bit inodes unless you tell it to via the inode64 mount option.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2006-10-05 0:37 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20061003060610.GV3024@melbourne.sgi.com>
2006-10-03 21:23 ` [RFC 0/3] Convert XFS inode hashes to radix trees Chris Wedgwood
2006-10-03 22:22 ` David Chinner
2006-10-04 0:47 ` Chris Wedgwood
2006-10-04 1:43 ` David Chinner
2006-10-04 19:22 ` Trond Myklebust
[not found] ` <20061003222256.GW4695059__33273.3314754025$1159914338$gmane$org@melbourne.sgi.com>
2006-10-04 17:59 ` Andi Kleen
2006-10-05 0:37 ` David Chinner
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox