On Mon, Aug 11, 2014 at 10:41 PM, Theodore Ts'o [off-list ref] wrote:

On Sat, Aug 09, 2014 at 12:39:58AM +0800, Li Xi wrote:

quoted

It is obvious that extended attribute implementation has performance
impact when creating files. That is why we choose to push the patches
which use internal inode field to save project ID.

Looking at your numbers more closely, I bit you are parsing the
extended attributes each time you need to adjust the project quota for
the file, correct?  I suspect that if you cache the project ID in the
in-memory struct ext4_inode_info, the performance difference between
using an extended attribute versus an internal inode field will be
negligible.  The only difference would be a tiny amount of CPU time
when you first create the inode, and when you read the inode from the
inode table block on disk, since the project ID will under normal
circumstances never or hardly ever change.

Yeah, I cached project ID in memory, not only for this internal inode field
implementation but also for xattr based implementation. Yeah, that is
right that reading project ID doesn't impact performance. However, as
the results shows, creating xattr costs extra time. That is why creating files
on xattr based implemetation is significantly slower than internal inode filed
implementation. Other operations won't be effected at all. We confirmed
this in varible way. If we remove xattr saving when creating files, the
performance will go up immediately. And also, we confirmed that ACL
has similar performance problem.

Regards,
Li Xi