On Tue, Apr 17, 2012 at 10:26:10AM +1000, Dave Chinner wrote: > > > You can't just blindly assert that something is needed purely on > > > the size of the filesystem. > > > > Thanks, but then perhaps the XFS FAQ needs updating. It warns that you might > > have compatibility problems with old clients (NFS) and inode64, but it > > doesn't say "for some workloads inode32 may perform better than inode64 on > > large filesystems". > > The FAQ doesn't say anything about whether inode32 performs better > than inode64 or vice versa. With respect it does, although in only three words: "Also, performance sucks". Maybe it would be useful to expand this. How about: "Also, performance sucks for many common workloads and benchmarks, such as sequentially extracting or reading a large hierarchy of files. This is because in filesystems >1TB without inode64, files created within the same parent directory are not created in the same allocation group with adjacent extents." If as you say inode32 was just a hack for broken NFS clients, then it seems to me that the *intended* default performance characteristics are those of inode64? That is, the designers considered this to be the most appropriate performance compromise for typical users? Regards, Brian. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
