Re: BTRFS messes up snapshot LV with origin

[Goffredo Baroncelli <kreijack@inwind.it>]

On 11/27/2014 05:15 AM, Zygo Blaxell wrote:
> On Wed, Nov 26, 2014 at 06:19:05PM +0100, Goffredo Baroncelli wrote:
>> On 11/25/2014 11:21 PM, Zygo Blaxell wrote:
>>>>> However I still doesn't understood why you want btrfs-w/multiple disk over LVM ?
>>> I want to split a few disks into partitions, but I want to create,
>>> move, and resize the partitions from time to time.  Only LVM can do
>>> that without taking the machine down, reducing RAID integrity levels,
>>> hotplugging drives, or leaving installed drives idle most of the time.
>>>
>>> I want btrfs-raid1 because of its ability to replace corrupted or lost
>>> data from one disk using the other.  If I run a single-volume btrfs
>>> on LVM-RAID1 (or dm-RAID1, or RAID1 at any other layer of the storage
>>> stack), I can detect lost data, but not replace it automatically from
>>> the other mirror.
>> OK, now I have understood.
>>
>> Anyway as workaround, take in account that you can pass explicitly the
>> devices as:
>>
>> mount -o device=/dev/sda,device=/dev/sdb,device=/dev/sdc /dev/sdd /mnt
>>
>> (supposing that the filesystem is on /dev/sda.../dev/sdd)
>>
>> I am working to a mount.btrfs helper. The aim of this helper is to manage
>> the assembling of multiple devices; the main points will be:
>> - wait until all the devices appeared
> 
> ...and make sure there are no duplicate UUIDs.
Yes, at the end I implemented in this way the "snapshot" detection:
if two autodetected devices have the same DISK_UUID (reported as 
SUB_UUID by blkid), th emount process stopped. I checked also the 
num_device field of the superblock.

> 
>> - allow (if required) to mount in degraded mode after a timeout
> 
> This is a terrible idea with current btrfs, at least for read-write
> degraded mounting (fallback to read-only degraded would be OK).
> Mounting a filesystem read-write and degraded is something you only want
> to do immediately before you replace all the missing disks and bring the
> filesystem up to a non-degraded space and after you've ensured that the
> missing disks can never, ever come back; otherwise, btrfs eats your data
> in a slightly different way than we have discussed so far...

I don't care. If the user pass "degraded" in the options of mount, 
he have it. Anyway this (wrong) btrfs behavior I hope that it will be
solved.
> 
>> - at this point it could/should also skip the lvm-snapshotted devices (but before 
>> I have to know how recognize these) 
> 
> You don't have to recognize them as snapshots (and it's probably better
> not to treat snapshots specially anyway--how do you know whether the
> snapshot or the origin LVs are wanted for mounting?).  You just have to
> detect duplicate UUIDs at the btrfs subdevice level, and if any are found,
> stop immediately (or get a hint from the admin).

For the disk autodetection, I still convinced that it is a "sane" default
to skip the lvm-snapshot

> 
> This is a weakness of the current udev and asynchronous device hotplug
> concept:  there is no notion of bus enumeration in progress, so we can be
> trying to assemble multi-device storage before we have all the devices
> visible.  Assembly of aggregate storage (whatever it is--btrfs, md,
> lvm2...) has to wait until all known storage buses are fully enumerated
> in order to detect if there are duplicates.

It is more complex than that. Some devices may appear after the "1st" bus
enumeration.


> 
>> I hope to issue the patches in the next week
>>
>> BR
>> G.Baroncelli
>>
>> -- 
>> gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
>> Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5