All of lore.kernel.org
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: BTRFS: error (device sda1) in btrfs_run_delayed_refs:2963: errno=-17 Object already exists
Date: Wed, 10 Aug 2016 06:41:21 +0000 (UTC)	[thread overview]
Message-ID: <pan$c10ae$cb8cb4bc$c1fc453b$eddc13d5@cox.net> (raw)
In-Reply-To: CAJCQCtRJhvwS2w1iRTxZbQ0tyfDH6Ser1=DBH6w+2Rq4pguf2A@mail.gmail.com

Chris Murphy posted on Tue, 09 Aug 2016 20:25:39 -0600 as excerpted:

> 1 size 50.93TiB used 22.67TiB path /dev/sda1
> 
> What is the exact nature of this block device?
> 
> If getting this back up and running is urgent I suggest inquiring on IRC
> what the next steps are.
> 
> In the meantime I'd get a btrfs-image (which is probably going to be
> quite large given metadata is 60GiB), if that pukes then see if 'btrfs
> inspect-internal dump-tree /dev/sda1 > dumptree.log' which may also fail
> but before it fails might contain something useful. Obviously btrfs
> check shouldn't crash so that's a bug already.

I'd suggest that at 50+ TB size, 22+ TB used, given btrfs check's known 
memory usage, the crash may well simply be due to lack of memory.  It's 
very likely that will require well over the 16 GiB memory that's 
reasonably common these days, and if there's no swap to fill in the gap...

There's a low memory mode check under development right now, but it's not 
complete yet.

(FWIW my usage is at the other extreme, quarter TB SSDs and partitioned 
down beyond that, so the largest btrfs is well under 50 GiB usable, tho 
it's pair-device raid1 so about 50 GiB total.  That's too small to be 
practical for many, but at least until the low-memory btrfs check or 
until 32 and 64 GiB RAM becomes common, single filesystems in the double-
digit TB may arguably be too big to be practical, at least for other than 
the lucky few with the sort of memory required, as well.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


  reply	other threads:[~2016-08-10 18:59 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-09 23:15 BTRFS: error (device sda1) in btrfs_run_delayed_refs:2963: errno=-17 Object already exists Matt McKinnon
2016-08-10  0:01 ` Chris Murphy
2016-08-10  0:06   ` Chris Murphy
2016-08-10  0:29     ` Matt McKinnon
2016-08-10  2:25       ` Chris Murphy
2016-08-10  6:41         ` Duncan [this message]
2016-08-11  1:51         ` Matt McKinnon
2016-08-10  0:56     ` Matt McKinnon
2016-08-10  0:17   ` Matt McKinnon
2016-08-10  7:09     ` g6094199
2016-08-10 11:16       ` Matt McKinnon
2016-08-10 20:43         ` g6094199

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='pan$c10ae$cb8cb4bc$c1fc453b$eddc13d5@cox.net' \
    --to=1i5t5.duncan@cox.net \
    --cc=linux-btrfs@vger.kernel.org \
    /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.