Re: Fragmentation Issue We Are Having

[Brian Candler <B.Candler@xxxxxxxxx>]

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