From: Eric Sandeen <sandeen@redhat.com>
To: Ric Wheeler <rwheeler@redhat.com>
Cc: Richard Scobie <richard@sauce.co.nz>,
"Majed B." <majedb@gmail.com>,
Leslie Rhorer <lrhorer@satx.rr.com>,
linux-raid@vger.kernel.org, Christoph Hellwig <hch@infradead.org>,
Eric Sandeen <esandeen@redhat.com>,
Dave Chinner <david@fromorbit.com>
Subject: Re: md software raid
Date: Wed, 28 Oct 2009 10:08:33 -0500 [thread overview]
Message-ID: <4AE85E71.30807@redhat.com> (raw)
In-Reply-To: <4AE76D98.7000003@redhat.com>
Ric Wheeler wrote:
> On 10/27/2009 08:50 PM, Richard Scobie wrote:
>> Majed B. wrote:
>>> Indeed xfs_repair doesn't require the abusive amount of memory
>>> xfs_check requires.
>>>
>>> I've been a happy XFS user for a few years now, but the fact the
>>> xfsprogs aren't being maintained properly and xfs_check is still a
>>> failure, I'm considering other alternatives.
>>
>> This should change soon, see the September entry:
>>
>> http://xfs.org/index.php/XFS_Status_Updates
>>
>> "On the userspace side a large patch series to reduce the memory usage
>> in xfs_repair to acceptable levels was posted, but not yet merged."
>>
>> Regards,
>>
>> Richard
>
> There are several people still actively working on both XFS & its tools
> and I am sure that they are interested in hearing about issues :-)
>
> ric
>
FWIW, this is merged now, but not yet in a usable release.
Still, existing xfs_repair has much better memory footprint than
xfs_check, and it is the tool you want to use whether you are just
checking (with -n) or repairing.
xfs_check is more or less deprecated; it is known to have large memory
requirements, and xfs_repair is the tool to use.
-Eric
next prev parent reply other threads:[~2009-10-28 15:08 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-23 9:11 md software raid ian.d
2009-10-23 9:38 ` Robin Hill
2009-10-27 10:19 ` Ian Docherty
2009-10-27 20:52 ` Bill Davidsen
2009-10-27 20:55 ` Richard Scobie
2009-10-27 21:15 ` Christopher Chen
2009-10-28 0:45 ` Leslie Rhorer
2009-10-28 0:47 ` Majed B.
2009-10-28 0:52 ` Leslie Rhorer
2009-10-28 0:58 ` Majed B.
2009-10-28 0:50 ` Richard Scobie
2009-10-27 22:00 ` Ric Wheeler
2009-10-28 15:08 ` Eric Sandeen [this message]
2009-10-28 16:06 ` Bernd Schubert
2009-10-28 23:39 ` Dave Chinner
2009-10-28 1:09 ` Max Waterman
2009-10-28 1:10 ` Majed B.
2009-10-28 2:03 ` Richard Scobie
2009-10-28 2:11 ` Leslie Rhorer
2009-10-28 2:26 ` Majed B.
2009-10-28 2:54 ` Leslie Rhorer
[not found] ` <4D87015385157D4285D56CA6101072FF3A6675B8@exchange07.valvesoftware.com>
2009-10-28 2:52 ` Majed B.
2009-10-28 3:26 ` Guy Watkins
2009-10-28 3:08 ` Leslie Rhorer
2009-10-28 3:11 ` Chris Green
2009-10-28 3:29 ` Leslie Rhorer
2009-11-05 13:51 ` Matt Garman
2009-10-28 3:35 ` Guy Watkins
2009-10-28 11:27 ` Max Waterman
2009-10-28 3:50 ` Christoph Hellwig
2009-10-28 6:37 ` Leslie Rhorer
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=4AE85E71.30807@redhat.com \
--to=sandeen@redhat.com \
--cc=david@fromorbit.com \
--cc=esandeen@redhat.com \
--cc=hch@infradead.org \
--cc=linux-raid@vger.kernel.org \
--cc=lrhorer@satx.rr.com \
--cc=majedb@gmail.com \
--cc=richard@sauce.co.nz \
--cc=rwheeler@redhat.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.