It does seem to be a little bit faster (maybe 10%)
with usrquota, grpquota and metaecc disabled.
The good news is that performance stayed pretty steady right through to the
end of the test. Performance dropped considerably from ~2500 to ~1500
files per second over the first 500,000 inodes, but
One more thing. When I straced one of the application processes (these are the
processes that create the files) I saw this:
% time seconds usecs/callcalls errors syscall
--- -- -- -- ---
68.94 3.002017 11127154open
18.93
On 02/01/2012 07:02 AM, Mark wrote:
One more thing. When I straced one of the application processes (these are
the
processes that create the files) I saw this:
% time seconds usecs/callcalls errors syscall
--- -- -- -- ---
68.94 3.002017
debugfs.ocfs2 -R stats /dev/mapper/...
I want to see the features enabled.
The main issue with large metdata is the fsck timing. The recently
tagged 1.8 release of the tools has much better fsck performance.
On 02/01/2012 05:25 AM, Mark Hampton wrote:
We have an application that has many
Here's what I got from debugfs.ocfs2 -R stats. I have to type it out
manually, so I'm only including the features lines:
Feature Compat: 3 backup-super strict-journal-super
Feature Incompat: 16208 sparse extended-slotmap inline-data metaecc xattr
indexed-dirs refcount discontig-bg
Feature RO
On 02/01/2012 10:24 AM, Mark Hampton wrote:
Here's what I got from debugfs.ocfs2 -R stats. I have to type it out
manually, so I'm only including the features lines:
Feature Compat: 3 backup-super strict-journal-super
Feature Incompat: 16208 sparse extended-slotmap inline-data metaecc
On Wed, Feb 1, 2012 at 1:27 PM, Sunil Mushran sunil.mush...@oracle.comwrote:
On 02/01/2012 10:24 AM, Mark Hampton wrote:
Here's what I got from debugfs.ocfs2 -R stats. I have to type it out
manually, so I'm only including the features lines:
Feature Compat: 3 backup-super
