[Top] [All Lists]

Re: [xfs_check Out of memory: ]

To: stan@xxxxxxxxxxxxxxxxx
Subject: Re: [xfs_check Out of memory: ]
From: Roger Willcocks <roger@xxxxxxxxxxxxxxxx>
Date: Mon, 30 Dec 2013 13:19:02 +0000
Cc: Roger Willcocks <roger@xxxxxxxxxxxxxxxx>, Dave Chinner <david@xxxxxxxxxxxxx>, Arkadiusz MiÅkiewicz <arekm@xxxxxxxx>, Stor?? <289471341@xxxxxx>, Jeff Liu <jeff.liu@xxxxxxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <52C0D281.7040704@xxxxxxxxxxxxxxxxx>
References: <tencent_3F12563342ED1D4E049D1123@xxxxxx> <201312270907.22638.arekm@xxxxxxxx> <20131227224212.GK20579@dastard> <201312280020.39244.arekm@xxxxxxxx> <20131229095033.GL20579@dastard> <52C0D281.7040704@xxxxxxxxxxxxxxxxx>
On 30 Dec 2013, at 01:55, Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx> 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.


<Prev in Thread] Current Thread [Next in Thread>