public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Goodwin <markgw@sgi.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs-oss <xfs@oss.sgi.com>
Subject: Re: [PATCH, needs new owner] xfs_repair memory optimization
Date: Sun, 25 Jan 2009 11:03:19 +1100	[thread overview]
Message-ID: <497BAC47.2030101@sgi.com> (raw)
In-Reply-To: <20090124142331.GA32688@infradead.org>



Christoph Hellwig wrote:
> On Fri, Jan 23, 2009 at 01:09:32PM +1100, Mark Goodwin wrote:
>> A known limitation of xfs_repair is the large amount of memory it
>> requires, depending on filesystem size and number of inodes, etc.
>>
>> The attached patch series, originally by Barry Bnaujok, is close to
>> being finished but requires a new owner to do some final testing and
>> polishing. It applies cleanly against top-of-tree xfsprogs-3.0.0
>
> I did a quick look over it on the plane today and it looks quite nice
> to me.

that sounds promising, maybe we have a new owner for this code ;-)

> I guess there are no patch descriptions left anywhere?

The patch series as posted is straight out of Barry's workarea.
The only descriptions are the patch filenames themselves and what's
still in Barry head - you could email him and he may or may not
respond. I do know that he spent quite a lot of time benchmarking
and stressing this code - it should be fairly robust and close to
release quality.

> Otherwise some of the patch might need some minor polishing, e.g.
> the patch moving over from the radix tree to the btree leaves the
> radix-tree implementation in, which gets removed in the next patch
> which has otherwise unrelated changes.

well you could split the radix removal from the unrelated changes,
but the end result is the same, right?

> The btree implementation btw worries me a little, 

all XFS btree implementations continue to be bit of a worry :)

> I wonder if we need
> a test harness to make sure it's correct for all corner cases.

Would the test harness for the factored kernel btrees be adaptable to this
one in userspace? (or could the kernel btree code also be adapted/shared
for use in userspace too?)

BTW, I think Barry also had some changes underway to xfs_repair phase-1,
e.g. to detect missing volume manager pieces (and thus abort the repair
rather than make a dogs breakfast), better backup superblock searching,
etc. He also had plans for utilizing parent pointers, e.g. to practically
eliminate lost+found.

Cheers
-- Mark

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

      reply	other threads:[~2009-01-25  0:04 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-23  2:09 [PATCH, needs new owner] xfs_repair memory optimization Mark Goodwin
2009-01-24 14:23 ` Christoph Hellwig
2009-01-25  0:03   ` Mark Goodwin [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=497BAC47.2030101@sgi.com \
    --to=markgw@sgi.com \
    --cc=hch@infradead.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox