On Wed, Mar 05, 2008 at 02:19:48PM -0500, Ric Wheeler wrote: > The work load is generated using fs_mark > (http://sourceforge.net/projects/fsmark/) which is basically a write > workload with small files, each file gets fsync'ed before close. The > metric is "files/sec". ....... > It would be really interesting to rerun some of these tests on xfs which > Dave explained in the thread last week has a more self tuning way to > batch up transactions.... Ok, so XFS numbers. note these are all on a CONFIG_XFS_DEBUG=y kernel, so there's lots of extra checks in the code as compared to a normal production kernel. Local disk (15krpm SCSI, WCD, CONFIG_XFS_DEBUG=y): threads files/s 1 97 2 117 4 109 8 110 10 113 20 116 Local disk (15krpm SCSI, WCE, nobarrier, CONFIG_XFS_DEBUG=y): threads files/s 1 203 2 216 4 243 8 332 10 405 20 424 Ramdisk (nobarrier, CONFIG_XFS_DEBUG=y): agcount=4 agcount=16 threads files/s files/s 1 1298 1298 2 2073 2394 4 3296 3321 8 3464 4199 10 3394 3937 20 3251 3691 Note the difference the amount of parallel allocation in the filesystem makes - agcount=4 only allows up to 4 parallel allocations at once, so even if they are all aggregated into the one log I/O, no further allocation can take place until that log I/O is complete. And at about 4000 files/s the system (4p ia64) is becoming CPU bound due to all the debug checks in XFS. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
