mirror of
git://sourceware.org/git/lvm2.git
synced 2025-03-10 16:58:47 +03:00
c87907dcd5
Two of the sync actions performed by the kernel (aka MD runtime) are "resync" and "recover". The "resync" refers to when an entirely new array is going through the process of initializing (or resynchronizing after an unexpected shutdown). The "recover" is the process of initializing a new member device to the array. So, a brand new array with all new devices will undergo "resync". An array with replaced or added sub-LVs will undergo "recover". These two states are treated very differently when failures happen. If any device is lost or replaced while "resync", there are no worries. This is because any writes created from the inception of the array have occurred to all the devices and can be safely recovered. Even though non-initialized portions will still be resync'ed with uninitialized data, it is ok. However, if a pre-existing device is lost (aka, the original linear device in a linear -> raid1 convert) during a "recover", data loss can be the result. Thus, writes are errored by the kernel and recovery is halted. The failed device must be restored or removed. This is the correct behavior. Unfortunately, we were treating an up-convert from linear as a "resync" when we should have been treating it as a "recover". This patch removes the special case for linear upconvert. It allows each new image sub-LV to be marked with a rebuild flag and treats the array as 'in-sync'. This has the correct effect of causing the upconvert to be treated as a "recover" rather than a "resync". There is no need to flag these two states differently in LVM metadata, because they are already considered differently by the kernel RAID metadata. (Any activation/deactivation will properly resume the "recover" process and not a "resync" process.) We make this behavior change based on the presense of dm-raid target version 1.9.0+.
This tree contains the LVM2 and device-mapper tools and libraries. For more information about LVM2 read the changelog in the WHATS_NEW file. Installation instructions are in INSTALL. There is no warranty - see COPYING and COPYING.LIB. Tarballs are available from: ftp://sourceware.org/pub/lvm2/ ftp://sources.redhat.com/pub/lvm2/ The source code is stored in git: https://sourceware.org/git/?p=lvm2.git git clone git://sourceware.org/git/lvm2.git Mailing list for general discussion related to LVM2: linux-lvm@redhat.com Subscribe from https://www.redhat.com/mailman/listinfo/linux-lvm Mailing lists for LVM2 development, patches and commits: lvm-devel@redhat.com Subscribe from https://www.redhat.com/mailman/listinfo/lvm-devel lvm2-commits@lists.fedorahosted.org (Read-only archive of commits) Subscribe from https://fedorahosted.org/mailman/listinfo/lvm2-commits Mailing list for device-mapper development, including kernel patches and multipath-tools: dm-devel@redhat.com Subscribe from https://www.redhat.com/mailman/listinfo/dm-devel The source code repository used until 7th June 2012 is accessible here: http://sources.redhat.com/cgi-bin/cvsweb.cgi/LVM2/?cvsroot=lvm2.