On Jul 14, 2013, at 3:08 PM, Stan Hoeppner wrote: > On 7/14/2013 11:14 AM, Eric Sandeen wrote: > >> 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. > > Agreed. > >> It'd be nice if they said what they were trying to accomplish rather than just giving you a long recipe. > > Again. > >> In the end, I think they are trying to create 128AGs and maybe work around some mkfs corner case or other. > > Or it's just as likely they are laying out these image frames in a > specific manner across 128 directories, assuming 128 AGs exist, to > achieve some specific "on disk" organization of the files. It's simply > not possible to know without more information. > > Interestingly, on a 14+2 RAID6 array of 7.2K drives, normally 128 AGs > will decrease parallel performance due to a huge increase in head seek > latency. Thus I'd assume this isn't a parallel workload. Either that > or Autodesk doesn't know XFS as well as they believe. Now hold on a minute here Stan. While I don't really like Autodesk as they pretty much atrophy software. The fact is that they, the finishing suite division, know XFS and realtime 2K performance is realized all day long as long as one follows there guidelines. After all, SGI developed XFS as well as visual computing stations and back in the day, you had SGIs running Flame vs today which is Linux. Flame is a visual computing app after all. Albeit with a front end or GUI tuned to artists but still. My initial post on this was to try and understand if there mobs make sense to the general XFS community and wether I could benefit from them in applying those mods to general purpose storage. - aurf _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
