Re: BTRFS messes up snapshot LV with origin

[Zygo Blaxell <zblaxell@furryterror.org>]

[-- Attachment #1: Type: text/plain, Size: 3001 bytes --]

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.

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

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

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.

> 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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]