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
next prev parent 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).