On Wed, 2003-10-29 at 13:09, Ravi Wijayaratne wrote:
> I wanted to find out what performance impact setting/getting extended
> attributes would have on file I/O on XFS. Therefore for every file I/O
> I set a 4 byte extended attribute in "user" name space. The performance
> dropped approximately 30%.
> I have the following questions regarding this observation.
> 1. Are extended attributes cached ? If so I should see a performance
> impact of perhaps doing stat which accesses the cached inode structures
> if present. Substituting a stat call instead of setxattr call, only had
> approximately 6% drop in performance. Why is the discrepency ?
Stat is a read only call, setting an extended attribute does a
transaction. There may not be disk I/O on all calls, but there
will be disk writes involved.
> 2. I know that inodes are cached. Are user name space EAs stored inside the
> inode ?
> If not, is there a user space utility or another name space, "system" or
> that I could use to force EAs to be stored inside the inode so that I can be
> that it will be cached ?
Caching is not the issue, you are changing them so you are updating
metadata. Extended attributes can be held inside the inode, but this
space is shared between attributes, extent information and directory
contents. If you want to be more sure of keeping them in the inode
then you can make the inodes larger at mkfs time.
> 3. Could setting extensive amounts of extended attributes disrupt the
> operations in the log and hence cause adverse effects ?
Well yes, since you are asking the filesystem to do more.