Extended Attribute Write Performance

[Andreas Dilger]

On Jan 12, 2006  20:52 -0500, Charles P. Wright wrote:
> On Thu, 2006-01-12 at 12:52 -0700, Andreas Dilger wrote: 
> > Presumably you are using ext3 and not ext2, given posting to this list?
>
> Actually this test case was on Ext2, not Ext3.  I did a quick search for
> an ext2-users list and didn't immediately see results, so I figured that
> as Ext2 and Ext3 have similar EA implementations, this list would be
> appropriate.

There is ext2-devel at lists.sourceforge.net, which is listed in the MAINTAINERS
file for ext2...  You are right that the same people read both lists.

> > Solutions to your specific problem are to use large inodes and the
> > fast EA space ("mke2fs -j -I 256 ..." makes 256-byte inodes, 128 bytes
> > left for EAs)
>
> Increasing the inode size to 256 bytes made a huge difference under
> Ext3.  The spikes that I mentioned for Ext2 also existed in Ext3, and
> were eliminated by this change.  My application's performance increased
> by about 40%, and the standard deviations dropped from around 20% to 4%.
> 
> However, for Ext2 it made very little difference.  I still have a
> handful of operations (.05%) that account for 73% of the time.  I know
> that Ext2 is optimized for shared attribute blocks (for the case of
> ACLs).  Is there something about having lots of unique attributes that
> results in poor performance?

There is no support for fast EAs in ext2 at this time, so it would only
slow things down there because you are writing more (useless) data to disk.

I honestly have no ideas about ext2 performance, as I only ever use ext3.
I would suspect that some of these operations are slower because they are
"stuck" with doing some extra amount of work, like reading a bitmap from
disk, and the rest of the operations are going to cache.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.