xfs
[Top] [All Lists]

Re: xattr performance

To: Ben Myers <bpm@xxxxxxx>
Subject: Re: xattr performance
From: Christian Kujau <lists@xxxxxxxxxxxxxxx>
Date: Fri, 17 May 2013 13:09:39 -0700 (PDT)
Cc: jfs-discussion@xxxxxxxxxxxxxxxxxxxxx, linux-ext4@xxxxxxxxxxxxxxx, linux-btrfs@xxxxxxxxxxxxxxx, reiserfs-devel@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20130517154436.GW29359@xxxxxxx>
References: <alpine.DEB.2.10.1305170444590.13746@xxxxxxxxxxxxxx> <20130517154436.GW29359@xxxxxxx>
User-agent: Alpine 2.10 (DEB 1266 2009-07-14)
On Fri, 17 May 2013 at 10:44, Ben Myers wrote:
> The short version:
> inode core (96 bytes) + literal area == inode size

Ah, yes indeed. I had another issue earlier on the same filesystem and 
Christoph told me[0] that I may have run out of inode attributes. 

xfs_info reports isize=256 for this filesystem and now that I'm using 
xattr even more (I'm storing sha256 checksum plus the filename in each 
file's xattr) this looks like it might exceed the literal area after all. 

> Anyway... If you're a heavy user of EAs you might benefit from using larger
> inodes.  Just something to consider.  Cool tests!  ;)

Yeah, next time I'll have to take this into consideration, but the fs was 
created long ago and I didn't plan to use xattr. Now I do but mkfs is not 
an option right now.

Thanks for the insight,
Christian.

[0] http://oss.sgi.com/archives/xfs/2012-07/msg00116.html
-- 
BOFH excuse #247:

Due to Federal Budget problems we have been forced to cut back on the number of 
users able to access the system at one time. (namely none allowed....)

<Prev in Thread] Current Thread [Next in Thread>