From: Stan Hoeppner <stan@hardwarefreak.com>
To: Roger Willcocks <roger@filmlight.ltd.uk>
Cc: Stor?? <289471341@qq.com>, Jeff Liu <jeff.liu@oracle.com>,
xfs@oss.sgi.com
Subject: Re: [xfs_check Out of memory: ]
Date: Mon, 30 Dec 2013 10:25:33 -0600 [thread overview]
Message-ID: <52C19E7D.3080706@hardwarefreak.com> (raw)
In-Reply-To: <1F5B96C2-84EB-43B2-ACE5-7C14E7803C9F@filmlight.ltd.uk>
On 12/30/2013 7:19 AM, Roger Willcocks wrote:
>
> On 30 Dec 2013, at 01:55, Stan Hoeppner <stan@hardwarefreak.com> wrote:
>
>> On 12/29/2013 3:50 AM, Dave Chinner wrote:
>> ...
>>> I think you are forgetting that developer time is *expensive* and
>>> *scarce*. This is essentially a solved problem: An SSD in a USB3
>>> enclosure as a temporary swap device is by far the most cost
>>> effective way to make repair scale to arbitrary amounts of metadata.
>>> It certainly scales far better than developer time and testing
>>> resources...
>>
>> Now this is an interesting idea Dave. I hadn't considered temporary
>> swap. Would USB be reliable enough for this? I've seen lots problem
>> reports with folks using USB storage with Linux, random disconnections
>> and what not.
>>
>
> I'll just chip in here and mention that we get around this problem by
> exporting the broken xfs volume over iscsi and run xfs-repair on another
> machine with more memory / swap space.
Another interesting, actually excellent idea Roger. So Arkadiusz could
get by with just one set of SSDs. Pulling ~40 GB of metadata over GbE
iSCSI should take only about 7 minutes of wire time, assuming his
hosts/net can sustain 100 MB/s.
--
Stan
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-12-30 16:25 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-27 6:48 [xfs_check Out of memory: ] Stor??
2013-12-27 7:41 ` Jeff Liu
2013-12-27 8:07 ` Arkadiusz Miśkiewicz
2013-12-27 22:42 ` Dave Chinner
2013-12-27 23:20 ` Arkadiusz Miśkiewicz
2013-12-28 16:55 ` Stan Hoeppner
2013-12-28 17:35 ` Jay Ashworth
2013-12-28 22:01 ` Stan Hoeppner
2013-12-28 23:39 ` Arkadiusz Miśkiewicz
2013-12-29 0:54 ` Stan Hoeppner
2013-12-29 11:23 ` Arkadiusz Miśkiewicz
2013-12-29 9:50 ` Dave Chinner
2013-12-29 11:57 ` Arkadiusz Miśkiewicz
2013-12-29 23:27 ` Dave Chinner
2013-12-30 1:55 ` Stan Hoeppner
2013-12-30 11:27 ` Matthias Schniedermeyer
2013-12-30 13:19 ` Roger Willcocks
2013-12-30 16:25 ` Stan Hoeppner [this message]
2013-12-30 17:19 ` Stefan Ring
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=52C19E7D.3080706@hardwarefreak.com \
--to=stan@hardwarefreak.com \
--cc=289471341@qq.com \
--cc=jeff.liu@oracle.com \
--cc=roger@filmlight.ltd.uk \
--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.