Re: fsck: to repair or not to repair

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

Henk Slager posted on Thu, 12 May 2016 19:02:56 +0200 as excerpted:

>  Maybe you first want to test it on an overlay
> of the device or copy the whole fs with dd.

WARNING!

Because btrfs can be multi-device, it needs some way to track which 
devices belong to each filesystem, and it uses filesystem UUID for this 
purpose.

If you clone a filesystem (for instance using dd or lvm snapshotting, 
doesn't matter how) and then trigger a btrfs device scan, say by plugging 
in some other device with btrfs on it so udev triggers a scan, and the 
kernel sees multiple devices with the same filesystem UUID as a result, 
and one of those happens to be mounted, you can corrupt both copies as 
the kernel btrfs won't be able to tell them apart and may write updates 
to the wrong one.

Prevention:

Don't let btrfs see both copies at the same time.  If you need to clone 
the filesystem, ideally make sure it's unmounted at the time, and detach 
either the original device or the clone immediately upon finishing the 
clone operation (before doing anything that might trigger a btrfs device 
scan, including device plugging that would trigger udev to trigger such a 
scan).  Then simply keep them separate, only attaching one at a time and 
DEFINITELY never mounting the filesystem with both the clone and the 
original devices attached, so the kernel can't get confused and write to 
the wrong one because the other one is never there at the same time to 
provide the opportunity.

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