All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Christoph Hellwig <hch@infradead.org>
Cc: Tomek Kruszona <bloodyscarion@gmail.com>,
	Eric Sandeen <sandeen@redhat.com>,
	Riku Paananen <riku.paananen@helsinki.fi>,
	xfs-oss <xfs@oss.sgi.com>
Subject: Re: [PATCH] libxfs: increase hash chain depth when we run out of slots
Date: Thu, 17 Sep 2009 14:02:32 -0500	[thread overview]
Message-ID: <4AB287C8.1030405@sandeen.net> (raw)
In-Reply-To: <20090917180931.GA21848@infradead.org>

Christoph Hellwig wrote:
> On Thu, Sep 17, 2009 at 11:06:16AM -0500, Eric Sandeen wrote:
>> A couple people reported xfs_repair hangs after
>> "Traversing filesystem ..." in xfs_repair.  This happens
>> when all slots in the cache are full and referenced, and the
>> loop in cache_node_get() which tries to shake unused entries
>> fails to find any - it just keeps upping the priority and goes
>> forever.
>>
>> This can be worked around by restarting xfs_repair with
>> -P and/or "-o bhash=<largersize>" for older xfs_repair.
>>
>> I started down the path of increasing the number of hash buckets
>> on the fly, but Barry suggested simply increasing the max allowed
>> depth which is much simpler (thanks!)
>>
>> Resizing the hash lengths does mean that cache_report ends up with
>> most things in the "greater-than" category:
>>
>> ...
>> Hash buckets with  23 entries      3 (  3%)
>> Hash buckets with  24 entries      3 (  3%)
>> Hash buckets with >24 entries     50 ( 85%)
>>
>> but I think I'll save that fix for another patch unless there's
>> real concern right now.
>>
>> I tested this on the metadump image provided by Tomek.
> 
> How large is that image?  I really think we need to start collecting
> these images for regression testing.

zipped metadump is 170M; unzipped 1.1G.

Crafting a special test fs somehow might be better; maybe with an
artificially low bhashsize or something ....  yeah, I know.  I'm not
sure how to manage the regression testing.  Working backwards to a
minimal testcase on these would be extremely time-consuming and/or
impossible I'm afraid.

> The patch looks good to me,

thanks for the review

-Eric

> 
> Reviewed-by: Christoph Hellwig <hch@lst.de>
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
> 

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

      reply	other threads:[~2009-09-17 19:01 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-17 16:06 [PATCH] libxfs: increase hash chain depth when we run out of slots Eric Sandeen
2009-09-17 18:09 ` Christoph Hellwig
2009-09-17 19:02   ` 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=4AB287C8.1030405@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=bloodyscarion@gmail.com \
    --cc=hch@infradead.org \
    --cc=riku.paananen@helsinki.fi \
    --cc=sandeen@redhat.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.