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 from 500,000 to 150,000,000 inodes performance was steady. Hopefully that will stay true when we get to 1 billion inodes. Again, splitting the inodes across multiple OCFS2 filesystems seemed to be a major factor to improving inode-creation performance (i.e. using the same hardware but slicing the NetApp volume into multiple LUNs instead of a single LUN). Is that what you would expect Sunil? On Wed, Feb 1, 2012 at 1:44 PM, Mark Hampton <m...@cleverdba.com> wrote: > On Wed, Feb 1, 2012 at 1:27 PM, Sunil Mushran <sunil.mush...@oracle.com>wrote: > >> 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 >>> xattr indexed-dirs refcount discontig-bg >>> Feature RO compat: 7 unwritten usrquota grpquota >>> >>> >>> Some other info that may be interesting: >>> >>> Links: 0 Clusters: 52428544 >>> >> >> >> I would disable quotas. That line suggests the vol is 200G is size. >> > > Ok, I'll try disabling quotas and metaecc. > > Yes, the filesystem is 200GB. This particular filesystem is 1 out of 16 > OCFS2 filesystems. This is a 1/5 scale test of what will be in production. > > I wonder if having 16 OCFS2 filesystems is ideal. 16 small OCFS2 > filesystems definitely performed better than 1 large OFCS2 filesystem. > Writing across 16 small OCFS2 filesystems turned out to be at least twice > as fast. I don't know what the optimal number is though. > > I noticed that there appear to be separate dlm process for each > filesystem, so maybe reducing serialization is a factor in the improved > performance? >
_______________________________________________ Ocfs2-users mailing list Ocfs2-users@oss.oracle.com http://oss.oracle.com/mailman/listinfo/ocfs2-users