[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 11-01-27 07:17 PM, Dave Chinner wrote:
    > In my experience with XFS, most people who tweak mkfs parameters end
    > up with some kind of problem they can't explain and don't know how
    > to solve. And they are typically problems that would not have
    > occurred had they simply used the defaults in the first place. What
    > you've done is a perfect example of this.

    Maybe. But what I read from the paragraph above,
    is that the documentation could perhaps explain things better,
    and then people other than the coders might understand how
    best to tweak it.

    > Why 8 AGs and not the default?

    How AGs are used is not really explained anywhere I've looked,
    so I am guessing at what they do and how the system might respond
    to different values there (that documentation thing again).

    Lacking documentation, my earlier experiences suggest that more AGs
    gives me less fragmentation when multiple simultaneous recording streams
    are active. I got higher fragmentation with the defaults than with
    the tweaked value.

    Now, that might be due to differences in kernel versions too,
    as things in XFS are continuously getting even better (thanks!),
    and the original "defaults" assessment was with the kernel-of-the-day
    back in early 2010 (2.6.34?), and now the system is using 2.6.37.

    But I just don't know. My working theory, likely entirely wrong,
    is that if I have N streams active, odds are that each of those
    streams might get assigned to different AGs, given sufficient AGs >= N.

    Since the box often has 3-7 recording streams active,
    I'm trying it out with 8 AGs now.


     \ /
      Last update: 2011-01-28 02:25    [W:0.034 / U:31.884 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site