linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: system hangs due to qgroups
Date: Mon, 5 Dec 2016 02:32:27 +0000 (UTC)	[thread overview]
Message-ID: <pan$8ca94$cc30e15b$935bf922$c3b45b75@cox.net> (raw)
In-Reply-To: 5831203.ygVuIMpfzH@thetick

Marc Joliet posted on Sun, 04 Dec 2016 20:20:51 +0100 as excerpted:

> On Sunday 04 December 2016 18:24:08 Duncan wrote:
>> Marc Joliet posted on Sun, 04 Dec 2016 17:02:48 +0100 as excerpted:

>> > [After trying it]
>> > 
>> > Well, crap, I was able to get images of the file system (one
>> > sanitized),
>> > but mounting always fails with "device or resource busy" (with no
>> > corresponding dmesg output).  (Also, that drive's partitions weren't
>> > discovered on bootup, I had to run partprobe first.)  I never see
>> > that in the initramfs, so I'm not sure what's causing that.
>> 
>> If I understand correctly what you're doing, that part is easily enough
>> explained.
>> 
>> Remember that btrfs, unlike most filesystems, is multi-device capable.
>> The way it tracks which devices belong to which filesystems is by UUID,
>> universally *UNIQUE* ID.  If you image a device via dd or similar, you
>> of course image its UUID as well, destroying the "unique" assumption in
>> UUID and confusing btrfs, which will consider it part of the existing
>> filesystem if the original devices with that filesystem UUID remain
>> hooked up.
>> 
>> So if you did what I believe you did, try to mount the image while the
>> original filesystem devices remain attached and mounted, btrfs is
>> simply saying that filesystem (which btrfs identifies by UUID) is
>> already mounted: "device or resource busy".
> [...]
> 
> Nope, sorry if I wasn't clear, I didn't mean that I tried to mount the
> image (can you even mount images created with btrfs-image?).  Plus the
> images are xz-compressed.

Namespace collision.

I interpreted "image" as referring to an "image" taken with dd or 
similar, which as I explained naturally copies the filesystem UUID as 
well, and if both that dd-created image and the original filesystem are 
visible to btrfs at the same time, bad things happen because btrfs 
considers them part of the same filesystem.

And if you tried to mount /that/ image while the original filesystem was 
already mounted, you /might/ get a busy error as it could think it was 
already mounted.  (And you'd be lucky if so, because it just might save 
you serious corruption, tho corruption might still happen due to btrfs 
writing to the image instead of the mounted original filesystem.)

I wasn't considering trying to mount the btrfs-created metadata images...

Anyway, as long as you weren't trying to mount or work with the dd-
created image at the same time as the original was mounted, you should be 
good.  Just remove one (or don't create the loopback device out of the 
image file so it's not exposed as a device that btrfs can see) before 
trying to mount the other and you should be good.

-- 
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-12-05  2:32 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-03 18:40 system hangs due to qgroups Marc Joliet
2016-12-03 20:42 ` Chris Murphy
2016-12-03 21:46   ` Marc Joliet
2016-12-03 22:56     ` Chris Murphy
2016-12-04 16:02       ` Marc Joliet
2016-12-04 18:24         ` Duncan
2016-12-04 19:20           ` Marc Joliet
2016-12-05  2:32             ` Duncan [this message]
2016-12-04 18:52         ` Chris Murphy
2016-12-05  9:00           ` Marc Joliet
2016-12-05 10:16             ` Marc Joliet
2016-12-05 23:22               ` Marc Joliet
2016-12-19 11:17                 ` Marc Joliet
2016-12-04  2:10     ` Adam Borowski
2016-12-04 16:02       ` Marc Joliet
2016-12-05  0:39 ` Qu Wenruo
2016-12-05 11:01   ` Marc Joliet
2016-12-05 12:10     ` Marc Joliet
2016-12-05 14:43     ` [SOLVED] " Marc Joliet
2016-12-06  0:29       ` Qu Wenruo
2016-12-06 10:12         ` Marc Joliet
2016-12-06 14:55           ` 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='pan$8ca94$cc30e15b$935bf922$c3b45b75@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 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).