[dm-devel] Possible bug in mirror target

[John Stoffel]

>>>>> "Zdenek" == Zdenek Kabelac <zkabelac at redhat.com> writes:

Zdenek> Dne 10. 02. 19 v 22:58 John Stoffel napsal(a):
>>>>>>> "Zdenek" == Zdenek Kabelac <zkabelac at redhat.com> writes:
>> 
Zdenek> Dne 05. 02. 19 v 1:47 Drew Hastings napsal(a):
>>>> Hi,
>>>> 
>>>> I'm assuming all user space code is expected to use the handle_errors feature,
>>>> so this isn't that big of a deal. I'm also using 4.19.13, which I think is
>>>> more recent than the latest update to dm-raid1.c
>>>> 
>>>> That said, there may be a bug that causes the entire mirror to crash if there
>>>> is an error on the first leg of the mirror, but not on the 2nd leg.
>>>> 
>>>> Works fine if you do cause IO errors on the 2nd leg:
>>>> 
>>>> root at kernel-dev:~# dmsetup create zerodev --table "0 1073741824 zero"
>>>> root at kernel-dev:~# dmsetup create errordev --table "0 1073741824 error"
>>>> 
>>>> 
>>>> root at kernel-dev:~# dmsetup create mirror-table --table "0 1073741824 mirror
>>>> core 2 524288 nosync 2 /dev/mapper/zerodev 0 /dev/mapper/errordev 0 0"
>> 
Zdenek> There are 2 operational modes for old dm mirror target.
Zdenek> One requires to handle errors externally. Please check i.e. the following
Zdenek> guide for mirror target:
>> 
Zdenek> https://wiki.gentoo.org/wiki/Device-mapper
>> 
Zdenek> Lvm2 is using 'dmeventd' to service this error handling
Zdenek> (i.e. dropping the mirror leg or allocating replacement one).
>> 
>> Is it time to remove the dm-mirror target then?  Or to deprecate it?
>> Or to just silently replace it with something that does the right
>> thing when errors happen?  I can't think of why *anyone* would want to
>> use the dm-mirror target as it now seems to work.


Zdenek> The old dm mirror works differently then new dm raid - so if
Zdenek> you have an old one present/running (i.e. LVM mirrored volume)
Zdenek> using this target - you need to have this target present to be
Zdenek> able to access such volume.

Ok, I see that.  I just wonder if A) anyone still uses this target and
B) if it should be deprecated since it doesn't provide the protections
that the dm_raid target provides.

Getting rid of legacy stuff isn't a bad thing... :-)

Zdenek> You can (in lvm2) convert such mirror to use newer dm raid
Zdenek> target - but this requires some extra space (even though very
Zdenek> small metadata volume) which is now required per each mirrored
Zdenek> leg.

Not a bad thing.

Zdenek> Both targets are still maintained and bugfixed.

Zdenek> There is also something about very high complexity of mdraid
Zdenek> code and relative simplicity of old mirror target.

I'm thinking about the complexity of maintaing both in parallel, when
the older one doesn't provide the protections of the newer one. 

Zdenek> As for comment about *anyone* - majority of users are
Zdenek> consuming DM targets via lvm2 - there you get this transition
Zdenek> automatically - when you ask to create mirrored LV - lvm2 will
Zdenek> use (if present in kernel) newer md raid variant.  If anyone
Zdenek> is using DM directly with 'dmsetup' command - it's assumed
Zdenek> these are skilled users familiar with kernel doc (dmsetup is
Zdenek> low-level admins tool).  Lvm2 should be seen as
Zdenek> 'friendly-face' of these DM targets - which otherwise do
Zdenek> require pretty complex setup. If you do not want to use lvm2,
Zdenek> the tool replacing lvm2 needs to reproduce this extra logic.

Right, so how many use the old version?