On Sun, Jul 14, 2013 at 02:06:43AM -0500, Stan Hoeppner wrote: > On 7/13/2013 11:20 PM, aurfalien wrote: > ... > >>> mkfs.xfs -f -l size=512m -d su=128k,sw=14 /dev/mapper/vg_doofus_data-lv_data > ... > >>> meta-data=/dev/mapper/vg_doofus_data-lv_data isize=256 agcount=32, agsize=209428640 blks > >>> = sectsz=512 attr=2, projid32bit=0 > >>> data = bsize=4096 blocks=6701716480, imaxpct=5 > >>> = sunit=32 swidth=448 blks > >>> naming =version 2 bsize=4096 ascii-ci=0 > >>> log =internal log bsize=4096 blocks=131072, version=2 > >>> = sectsz=512 sunit=32 blks, lazy-count=1 > >>> realtime =none extsz=4096 blocks=0, rtextents=0 > ... > > Autodesk has this software called Flame which requires very very fast local storage using XFS. > > If "Flame" does any random writes then you probably shouldn't be using > RAID6. Oh, we are talking about flame/smoke/lustre rendering environments here. Go back 5 years, a renderwall compositing effects via smoke was one of the nastiest small random write workloads you could throw at a filesystem. It was often used to benchmark file server performance for renderwalls and still may be. Think of a workload that reads lots of shared texture files across thousands of machines, each crunching a single video frame to add an effect and all doing small random writes to the video frame as it modifies a small section of each line of the video frame.... Translation: tuning for AG size is a waste of time. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
