Hi there, On Thu, Jun 01, 2006 at 06:45:17AM -0600, Matthew Wilcox wrote: > On Wed, May 31, 2006 at 08:24:18PM -0700, Valerie Henson wrote: > We don't even need 64-bit inode numbers -- we can use special direntries > for shadow inodes, and inodes which refer to continuation inodes need > a new encoding scheme anyway. Normal inodes would remain 32-bit and > refer to the local domain, and shadow/continuation inode numbers would > be 32-bits of domain, plus 32-bits of inode within that domain. Be careful of 64 bit inode numbers, we have had a world of pain with those due to broken userspace applications that cannot work with larger inode numbers (backup programs, with on-disk formats that only have room for 32 bits). To the point that we're actually having to find new ways to keep our inode number space within the 32 bits-of-significance range. > > > Surely XFS must have a more elegant solution than this? Do you mean to the problem of inodes spanning multiple devices? We don't really have this concept in XFS today, but it remains an area of active interest (and current development). Or are you refering to the problem of scaling in general? Yes, XFS uses many approaches there, it was designed with this in mind. The first step toward an "elegent solution" is to use 64 bit disk addressing, or to at least be able to. > Well, yes. I think that inside the Linux XFS implementation > there's a small and neat filesystem struggling to get out. Hmm, interesting theory. In reality, no - all the complexity in XFS is in core places, that no matter how the code is sliced and diced still need to be done... the allocator, the log code, and the multiple Btrees could all possibly be simpler, but they are all critical pieces of XFS's ability to scale upward, and all have seen many years of tuning under a large variety of workloads. > For fun, if you're a masochist, try to follow the code flow for > something easy like fsync(). > ... > Finally, xfs_fsync actually does the work. The best bit about all this > abstraction is that there's only one xfs_vnodeops defined! No, the best bit is that an abstraction like this is a neat fit to the problems presented by this multiple-devices-within-one-filesystem approach. As I said, this is an area of active interest to us also. cheers. -- Nathan - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
