Hi David, I regret for making comments and questions on this quite late (somehow I missed to email). It does appear to me that using this approach can potentially help in cluster hash list related ma
Yes, there is less parallelism in the radix tree approach, as I stated in the original description. Sure, but tuning for specsfs is not the problem we are trying to solve here. The problem we are sol
Hi David, I regret for making comments and questions on this quite late (somehow I missed to email). It does appear to me that using this approach can potentially help in cluster hash list related ma
Yes, there is less parallelism in the radix tree approach, as I stated in the original description. Sure, but tuning for specsfs is not the problem we are trying to solve here. The problem we are sol
One of the long standing problems with XFS on large machines and filesystems is the sizing of the inode cache hashes used by XFS to index the xfs_inode_t structures. The mount option ihashsize became
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 whil
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
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
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
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 C