This is a discussion on RE: xattr performance and Samba4 - Samba ; Andrew, There are 2 more experiments that would definitely be worth running: 1) with the current benchmark config and XFS filesystem, increase the log size to maximum (32768 blocks) 2) With ext3 and the 400M journal, increase the running time ...
There are 2 more experiments that would definitely be worth running:
1) with the current benchmark config and XFS filesystem, increase the log
size to maximum (32768 blocks)
2) With ext3 and the 400M journal, increase the running time of the
benchmark to say 600 secs?
Have theory, need confirmation!
[mailto:email@example.com] On Behalf Of
Sent: Wednesday, 1 December 2004 12:12 PM
Subject: Re: xattr performance and Samba4
I've been following up on some ext3 tuning option to see whether we can get
decent xattr performance.
In particular I've been looking at a suggest from the clusterfs folks on
using a larger journal (by using the -J size=XXX option to mke2fs) and using
larger inodes (using the -I option with the current 2.6.10 kernel patch from
Here are the results:
green: default setup (which is what most users will get).
red: a 256 byte inode is used with the large inode patch
mauve: 400M journal is used with default inode size
blue: both a 400M journal and a 256 byte inode are used
I'm delighted with this! It means that it is possible to get excellent and
extremely scalable results with a Linux journaled filesystem and Samba4.
The other results that are interesting are:
that shows the dbench3 performance with and without the large inode size,
and with and without xattrs. It demonstrates that using xattrs in Samba4
will cost us extremely little once this patch hits mainstream kernels. The
tiny cost will be totally swamped by the noise once you use this in a full
Samba setup, intead of just in dbench.
The only downside is that admins will need to use special options to create
their filesystems, as the default performance is awful. I've suggested some
changes to the defaults to the extfs developers.