>> http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/cmds/xfsprogs.git;a=blob;f=mkfs/xfs_mkfs.c;h=5084d755;hb=HEAD#l688 >> >> Might be a good idea to do some benchmarking with different AG numbers? > > > Could be useful, but we should first get Swift to not dump everything in the > same AG. Otherwise, the benchmarks will be pretty predictable. ;) Yes, having increased # of AGs should help. Each AG has its own inode and free space management [1]. As amount of data increases, the data structures (B-tree?) used for tracking inodes would get bigger and bigger and slow things down. Increased # of AGs should help with concurrency as well as keeping the size of the B-trees small and therefore run faster. What is unclear right now is the overhead of creating multiple AGs in terms of disk space and memory. I will run some of these experiments over the next few days and report the results. [1] http://xfs.org/docs/xfsdocs-xml-dev/XFS_Filesystem_Structure/tmp/en-US/html/Allocation_Groups.html