linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc Joliet <marcec@gmx.de>
To: linux-btrfs@vger.kernel.org
Subject: Re: [4.7.2] btrfs_run_delayed_refs:2963: errno=-17 Object already exists
Date: Wed, 01 Mar 2017 19:14:07 +0100	[thread overview]
Message-ID: <14737660.8idzxVKBRv@thetick> (raw)
In-Reply-To: <63cf74bb-009a-b422-4390-7562395db31d@cn.fujitsu.com>

[-- Attachment #1: Type: text/plain, Size: 2503 bytes --]

On Wednesday 01 March 2017 17:32:35 Qu Wenruo wrote:
> At 03/01/2017 04:23 PM, Marc Joliet wrote:
> > On Tuesday 28 February 2017 23:14:54 Marc Joliet wrote:
> >> I think I'm at that point now myself, unless anybody has any other ideas.
> > 
> > For example, could the --init-extent-tree option to btrfs-check help,
> > given
> > that I needed to pass -w to btrfs-image?

(First off, thanks for taking the time to respond!)

> --init-extent-tree should be avoided normally, unless you're 100% sure
> about only extent tree is corrupted, and you have enough faith that
> --init-extent-tree can finish.
> 
> Or it will mostly make things worse.

OK, that's why I asked :) .

> Before trying any RW btrfs check operations, did you run btrfs check on
> the image?

If by image you mean the device in question, not since the last time (see my 
previous messages).  Or can I really run btrfs check on the image?  In any 
case, I started btrfs-check on the device itself.

> And btrfs check --mode=lowmem is also recommended as in some rare case,
> low mem mode can detect bug which original mode doesn't.

I did see differences in output the last time around (again, see my previous 
messages in this thread), so I'll run with lowmem.  It won't be done until 
tomorrow, though.

> (And it also helps us to enhance lowmem mode)

OK

> > Also, the image is complete, so I only need to find somewhere where I can
> > upload a 9.4 GB file.
> 
> Is it a compressed dump? Dumped with btrfs-image -c9?

It was created with:

btrfs-image -s -w /dev/sdb2 - | xz -9 --stdout > ./btrfs_backup_drive_2.img.xz

(Mainly because I felt more comfortable using a separate compression utility, 
not for any rational reason.  Although if you really meant "image" above, I 
have the feeling I'll regret this decision.)

> If so, such large one won't help much unless there is some developer
> really interested in inspecting the image.

When I started without compression, it was something like 46 GB, after only 
1-2 hours, so I expect the uncompressed size to be... very large :-/ .

> Thanks,
> Qu
> 
> > Greetings
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Greetings
-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

  reply	other threads:[~2017-03-01 18:15 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-28 13:29 [4.7.2] btrfs_run_delayed_refs:2963: errno=-17 Object already exists Kai Krakow
2017-02-02 12:01 ` Marc Joliet
2017-02-03 22:44   ` Kai Krakow
2017-02-10 22:15     ` Marc Joliet
2017-02-11  2:01       ` Kai Krakow
2017-02-11 10:18         ` Marc Joliet
2017-02-14 12:52           ` Marc Joliet
2017-02-17  8:19             ` Kai Krakow
2017-02-28 22:14               ` Marc Joliet
2017-03-01  8:23                 ` Marc Joliet
2017-03-01  9:32                   ` Qu Wenruo
2017-03-01 18:14                     ` Marc Joliet [this message]
2017-03-01 18:27                       ` Marc Joliet
2017-03-01 18:43                       ` Marc Joliet
2017-03-02  9:44                       ` Marc Joliet
2017-03-03  1:09                         ` Qu Wenruo
2017-03-03 11:26                           ` Marc Joliet
2017-03-05 23:53                       ` Marc Joliet
2017-03-06 11:18                         ` Marc Joliet
2017-03-02  0:43   ` Qu Wenruo
2017-03-02  9:43     ` Marc Joliet
2017-03-03  1:00       ` Qu Wenruo
2017-03-03 11:54         ` Marc Joliet

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=14737660.8idzxVKBRv@thetick \
    --to=marcec@gmx.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).