On Sun, Jul 14, 2013 at 10:14:15AM -0700, aurfalien wrote: > On Jul 14, 2013, at 9:14 AM, Eric Sandeen wrote: > > On 7/13/13 11:20 PM, aurfalien wrote: > >> On Jul 13, 2013, at 7:13 PM, Eric Sandeen wrote: > >>> On 7/13/13 7:11 PM, aurfalien wrote: > >>>> Hello again, > >>>> > >>>> I have a Raid 6 x16 disk array with 128k stripe size and a > >>>> 512 byte block size. > >>>> > >>>> So I do; > >>>> > >>>> mkfs.xfs -f -l size=512m -d su=128k,sw=14 > >>>> /dev/mapper/vg_doofus_data-lv_data > >>>> > >>>> And I get; > >>>> > >>>> 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 > >>>> > >>>> > >>>> All is fine but I was recently made aware of tweaking agsize. > >>> > >>> Made aware by what? For what reason? > >> > >> Autodesk has this software called Flame which requires very > >> very fast local storage using XFS. They have an entire write up > >> on how to calc proper agsize for optimal performance. > > > > http://wikihelp.autodesk.com/Creative_Finishing/enu/2012/Help/05_Installation_Guides/Installation_and_Configuration_Guide_for_Linux_Workstations/0118-Advanced118/0194-Manually194/0199-Creating199 > > > > I guess? > > > > That's quite a procedure! And I have to say, a slightly strange > > one at first glance. > > > > It'd be nice if they said what they were trying to accomplish > > rather than just giving you a long recipe. > > > Sorry to double reply to the same thread. > > But the volume in question (regarding the Autodesk article) is > used for very fast playback of image files. So realtime > performance for files of 2048x1556 resolution. These files are > being touched/retouched throughout the day by the person driving > the Flame. Sure - it's file per frame video that is being used here, and 2k resolution is generally around 12.5MB per frame. If you are concerned about playback rates, then it is far more important that the frames are laid out sequentially on disk than anything else. Tuning the number of AGs doesn't acheive that - increasing the number of AGs is more likely to cause them to be written all over the place, especially as the filesystem ages and AGs fill up. > The fragmentation on these systems on a heavy day, meaning one > were they are running at 98% full is about 5% on avg. On any > given day, the systems are about 80% full. If they are running their filesystems to 98% full, they they have already given up any hope they have of getting reliable layout of their video files. If you are concerned about low latency, high throughput playback, then it's far more important to get the stripe width set up correctly for the size of the file so each frame is stripe width aligned and each frame takes a single physical IO to read from disk and there is minimal seek between the two frames. The only reason I can see for increasing the number of AGs here is that they are trying to limit the number of video directories that share the same AGs as they are specifying the inode64 mount option. i.e. the assumption is that each video clip is sufficiently large that with 128AGs it is unlikely that two video clips will end up in the same AG and hence potentially interleave as they are modified.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
