Re: performance of filesystem xattrs with Samba4

[tridge]

Nathan,

 > I'm curious why you went to 2K inodes instead of 512 - I guess
 > because thats the largest inode size with a 4K blocksize?  If
 > the defaults were changed, I expect it would be to switch over
 > to 512 byte inodes - do you have numbers for that?

It was a fairly arbitrary choice. For the test I was running the
xattrs were small (44 bytes), so 512 would have been fine, but some
other tests I run use larger xattrs (for NT ACLs, streams, DOS EAs
etc). 

 > Ah great, thanks, I'll be keen to try that when its available.

It's now released. You can grab it at:

  http://samba.org/ftp/tridge/dbench/dbench-3.0.tar.gz

It should produce much more consistent results than previous versions
of dbench, plus it has a -x option to enable xattr support. Other
changes include:

 - the runs are now time limited, rather than being a fixed number of
   operations. This gives much more consisten results, especially for
   fast machines.

 - I've changed the mapping of the filesystem operations to be much
   closer to what Samba4 does, including the directory scans for case
   insensitivity, the stat() calls in name resolution and things like
   statfs() calls. The modelling could still be improved, but its
   much better than it was.

 - the load file is now compatible with the smbtorture NBENCH test
   again (the two diverged a while back).

 - the default load file has been updated to be based on NetBench
   7.0.3, running a enterprise disk mix.

 - the warmup/execute/cleanup phases are now better separated

Cheers, Tridge
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/