On Thu, Jan 27, 2011 at 10:12:23AM -0500, Mark Lord wrote: > On 11-01-27 12:30 AM, Stan Hoeppner wrote: > > Mark Lord put forth on 1/26/2011 9:49 PM: > > > >> agcount=7453 > > > > That's probably a bit high Mark, and very possibly the cause of your problems. > > :) Unless the disk array backing this filesystem has something like 400-800 > > striped disk drives. You said it's a single 2TB drive right? > > > > The default agcount for a single drive filesystem is 4 allocation groups. For > > mdraid (of any number of disks/configuration) it's 16 allocation groups. > > > > Why/how did you end up with 7452 allocation groups? That can definitely cause > > some performance issues due to massively excessive head seeking, and possibly > > all manner of weirdness. > > This is great info, exactly the kind of feedback I was hoping for! > > The filesystem is about a year old now, and I probably used agsize=nnnnn > when creating it or something. > > So if this resulted in what you consider to be many MANY too MANY ags, > then I can imagine the first new file write wanting to go out and read > in all of the ag data to determine the "best fit" or something. > Which might explain some of the delay. > > Once I get the new 2TB drive, I'll re-run mkfs.xfs and then copy everything > over onto a fresh xfs filesystem. > > Can you recommend a good set of mkfs.xfs parameters to suit the characteristics > of this system? http://xfs.org/index.php/XFS_FAQ#Q:_I_want_to_tune_my_XFS_filesystems_for_.3Csomething.3E And perhaps you want to consider the allocsize mount option, though that shouldn't be necessary for 2.6.38+... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
