All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Michael Monnerie <michael.monnerie@is.it-management.at>
Cc: Eric Sandeen <sandeen@redhat.com>,
	"Assarsson, Emil" <Emil.Assarsson@sonyericsson.com>,
	stan@hardwarefreak.com, xfs@oss.sgi.com
Subject: Re: XFS memory recomendation?
Date: Sun, 19 Feb 2012 15:00:15 -0600	[thread overview]
Message-ID: <4F4162DF.4000907@sandeen.net> (raw)
In-Reply-To: <5722408.cXkY2gHLh8@saturn>

On 2/19/12 7:16 AM, Michael Monnerie wrote:
> Am Freitag, 17. Februar 2012, 18:17:46 schrieb Eric Sandeen:
>> http://xfs.org/index.php/XFS_FAQ#Q:_Which_factors_influence_the_memory
>> _usage_of_xfs_repair.3F
> 
> I tried that, and it said "use 434":

That's megabytes, FWIW.

> xfs_repair -n -vv -m 1 /dev/mapper/vg_orion-lv_orion_data 
> Phase 1 - find and verify superblock...
>         - max_mem = 1024, icount = 339648, imem = 1326, dblock = 
> 805304256, dmem = 393214
> Required memory for repair is greater that the maximum specified with 
> the -m option. Please increase it to at least 434.
> 
> But when I tried with 
> # xfs_repair -n -vv -m 434 /dev/mapper/vg_orion-lv_orion_data 
> it said the same again. It only worked with 435:
> # xfs_repair -n -vv -m 435 /dev/mapper/vg_orion-lv_orion_data 
> (is that what you call an off-by-1 error?)

Yep, but really not too serious, I guess, still worth fixing though.

It's only used to try to enforce the bare minimum - in reality you'd
want more than that.

> Maybe that has been fixed already? This is
> # xfs_repair -V
> xfs_repair Version 3.1.6
> 
> BTW, this XFS is 3219644160 KB (3,2TB), used 2,9TB, has (df -i) 325364 
> inodes used, 293884 files in 31643 dirs. It seems mem usage primarily 
> comes from inodes, not from the size of the filesystem.

        _("        - max_mem = %lu, icount = %" PRIu64 ", imem = %" PRIu64 ", db
lock = %" PRIu64 ", dmem = %" PRIu64 "\n"),
                                max_mem, mp->m_sb.sb_icount,
                                mp->m_sb.sb_icount >> (10 - 2),
                                mp->m_sb.sb_dblocks,
                                mp->m_sb.sb_dblocks >> (10 + 1));

so yes, inodes in use count for more in the approximation.

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

      reply	other threads:[~2012-02-19 21:00 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-16 11:50 XFS memory recomendation? Assarsson, Emil
2012-02-17  2:49 ` Dave Chinner
2012-02-17 13:05   ` Michael Monnerie
2012-02-17 15:27     ` Assarsson, Emil
2012-02-18  1:14       ` Eric Sandeen
2012-02-18  1:58   ` Stan Hoeppner
2012-02-18  2:17     ` Eric Sandeen
2012-02-19 13:16       ` Michael Monnerie
2012-02-19 21:00         ` Eric Sandeen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F4162DF.4000907@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=Emil.Assarsson@sonyericsson.com \
    --cc=michael.monnerie@is.it-management.at \
    --cc=sandeen@redhat.com \
    --cc=stan@hardwarefreak.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.