On Fri, Sep 01, 2017 at 11:01:30PM +, Josef Bacik wrote:
> You'll be fine, it's only happening on the one fs right? That's 13gib of
> metadata with checksums and all that shit, it'll probably look like 8 or 9gib
> of ram worst case. I'd mount with -o ref_verify and check the slab amount in
Oops, ok I've updated my tree so we don't save the stack trace of the initial
scan, which we don't need anyway. That should save a decent amount of memory
in your case. It was an in place update so you'll need to blow away your local
branch and pull the new one to get the new code. Thanks,
J
I've just had this happen for the 3rd time in 4 days. I wasn't
suibscribed to the list so couldn't reply to the existing thread but
here it is http://www.spinics.net/lists/linux-btrfs/msg68662.html
I can do some limited testing. It's my main dev machine though..
On Sat, Sep 2, 2017 at 10:52 AM
:
gfp_mask=0x14000c0(GFP_KERNEL), nodemask=(null), order=0, oom_score_adj=0
[ 358.753716] bcache_writebac cpuset=/ mems_allowed=0
[ 358.769071] CPU: 3 PID: 2339 Comm: bcache_writebac Tainted: G U
4.13.0-rc5-amd64-stkreg-sysrq-20170902+ #2
[ 358.802040] Hardware name: System manufact
itebac cpuset=/ mems_allowed=0
> [ 358.769071] CPU: 3 PID: 2339 Comm: bcache_writebac Tainted: G U
> 4.13.0-rc5-amd64-stkreg-sysrq-20170902+ #2
> [ 358.802040] Hardware name: System manufacturer System Product Name/P8H67-M
> PRO, BIOS 3904 04/27/2013
> [ 358.8
On Sun, Sep 03, 2017 at 12:30:07AM +, Josef Bacik wrote:
> My bad, I forgot I don't dynamically allocate the stack trace space so my
> patch did nothing, I blame the children for distracting me. I've dropped
> allocating the action altogether for the on disk stuff, that should
> dramaticall
I was looking through the code for other ways to cut down memory usage when I
noticed we only catch improper re-allocations, not adding another ref for
metadata which is what I suspect your problem is. I added another patch and
pushed it out, sorry for the churn.
Josef
Sent from my iPhone
>
