[lkml]   [2011]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: xfs: very slow after mount, very slow at umount

On Thu, 27 Jan 2011, 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? Eg. Only a few thousand active inodes, and nearly all files are
> in the 600MB -> 20GB size range. The usage pattern it must handle is up to
> six concurrent streaming writes at the same time as up to three streaming reads,
> with no significant delays permitted on the reads.
> That's the kind of workload that I find XFS handles nicely,
> and EXT4 has given me trouble with in the past.
> Thanks

Hi Mark,

I did a load of benchmarks a long time ago testing every mkfs.xfs option
there was, and I found that most of the time (if not all), the defaults
were the best.


 \ /
  Last update: 2011-01-27 16:43    [W:0.072 / U:0.356 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site