We've since merged something
that stripes over several small xattrs so that we can keep things inline,
but it hasn't been backported to hammer yet. See
c6cdb4081e366f471b372102905a1192910ab2da.
Hi Sage:
You wrote yet - should we earmark it for hammer backport?
Nathan
On Wed, Jun 17, 2015 at 1:02 PM, Nathan Cutler ncut...@suse.cz wrote:
We've since merged something
that stripes over several small xattrs so that we can keep things inline,
but it hasn't been backported to hammer yet. See
c6cdb4081e366f471b372102905a1192910ab2da.
Hi Sage:
You wrote yet -
On Wed, 17 Jun 2015, Nathan Cutler wrote:
We've since merged something
that stripes over several small xattrs so that we can keep things inline,
but it hasn't been backported to hammer yet. See
c6cdb4081e366f471b372102905a1192910ab2da.
Hi Sage:
You wrote yet - should we earmark it
Guang,
Try to play around with the following conf attributes specially
filestore_max_inline_xattr_size and filestore_max_inline_xattrs
// Use omap for xattrs for attrs over
// filestore_max_inline_xattr_size or
OPTION(filestore_max_inline_xattr_size, OPT_U32, 0) //Override
On Wed, 17 Jun 2015, Zhou, Yuan wrote:
FWIW, there was some discussion in OpenStack Swift and their performance
tests showed 255 is not the best in recent XFS. They decided to use large
xattr boundary size(65535).
https://gist.github.com/smerritt/5e7e650abaa20599ff34
If I read this
After back-porting Sage's patch to Giant, with radosgw, the xattrs can get
inline. I haven't run extensive testing yet, will update once I have some
performance data to share.
Thanks,
Guang
Date: Tue, 16 Jun 2015 15:51:44 -0500
From: mnel...@redhat.com
To: yguan...@outlook.com;
Hi Yuan,
Thanks for sharing the link, it is interesting to read. My understanding of the
test results, is that with a fixed size of xattrs, using smaller stripe size
will incur larger latency for read, which kind of makes sense since there are
more k-v pairs, and with the size, it needs to get
