Re: system hangs due to qgroups

[Duncan <1i5t5.duncan@cox.net>]

Marc Joliet posted on Sun, 04 Dec 2016 17:02:48 +0100 as excerpted:

> That's a good idea, although I'll probably start with sysrescuecd (Linux
> 4.8.5 and btrfs-progs 4.7.3), as I already have experience with it.
> 
> [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".

Furthermore, if the original filesystem remains mounted writable, you're 
at serious risk of (further) corruption, because btrfs now considers them 
part of the same filesystem and may write partial updates to the wrong 
one!

Bottom line, with btrfs, make sure your universally UNIQUE IDs remain 
what they say on the tin, UNIQUE.  When you do clones including the UUID, 
don't expose the new image files as devices to btrfs while the original 
filesystem remains mounted!  Because btrfs /depends/ on UUIDs actually 
being what they say on the tin, UNIQUE.

(And FWIW, this discussion has occurred before on the list.  The btrfs 
assumption of UUID uniqueness is apparently embedded deeply enough in 
btrfs code that it can't be practically removed.  The entire thing would 
have to be rewritten; we're talking man-years worth of work.  So it's not 
going to happen and if it did the result would no longer be btrfs.  It 
may be possible to make btrfs a bit safer in terms of refusing to mount 
and/or going read-only if new devices with the same UUIDs appear in 
ordered to avoid corruption, but the basic UUID uniqueness assumption 
itself is apparently buried deeply enough in btrfs that it's not going to 
be possible to change that.  Starting fresh with a new filesystem project 
would be easier.)

-- 
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