Thanks for the response.
Assuming there is sufficient space in the inode, is it guaranteed
that the extended attribue will be stored in the inode and hence
in the inode cache ?
--- Steve Lord <lord@xxxxxxx> wrote:
> On Wed, 2003-10-29 at 13:09, Ravi Wijayaratne wrote:
> > Hi,
> > 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
> > "root"
> > that I could use to force EAs to be stored inside the inode so that I can
> > be assured
> > 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
> > transactional
> > operations in the log and hence cause adverse effects ?
> Well yes, since you are asking the filesystem to do more.
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears