All of lore.kernel.org
 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 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.