mirror of
git://sourceware.org/git/lvm2.git
synced 2024-10-28 11:55:55 +03:00
LVM2 mirror repository
https://sourceware.org/lvm2/
0f2f8a5c3a
Arrange mdas so mdas that are to be ignored come first. This is an optimization that ensures consistency on disk for the longest period of time. This was noted by agk in review of the v4 patchset of pvchange-based mda balance. Note the following example for an explanation of the background: Assume the initial state on disk is as follows: PV0 (v1, non-ignored) PV1 (v1, non-ignored) PV2 (v1, non-ignored) PV3 (v1, non-ignored) If we did not sort the list, we would have a commit sequence something like this: PV0 (v2, non-ignored) PV1 (v2, ignored) PV2 (v2, ignored) PV3 (v2, non-ignored) After the commit of PV0's mdas, we'd have an on-disk state like this: PV0 (v2, non-ignored) PV1 (v1, non-ignored) PV2 (v1, non-ignored) PV3 (v1, non-ignored) This is an inconsistent state of the disk. If the machine fails, the next time it was brought back up, the auto-correct mechanism in vg_read would update the metadata on PV1-PV3. However, if possible we try to avoid inconsistent on-disk states. Clearly, because we did not sort, we have a greater chance of on-disk inconsistency - from the time the commit of PV0 is complete until the time PV3 is complete. We could improve the amount of time the on-disk state is consistent by simply sorting the commit order as follows: PV1 (v2, ignored) PV2 (v2, ignored) PV0 (v2, non-ignored) PV3 (v2, non-ignored) Thus, after the first PV is committed (in this case PV1), on-disk we would have: PV0 (v1, non-ignored) PV1 (v2, ignored) PV2 (v1, non-ignored) PV3 (v1, non-ignored) This is clearly a consistent state. PV1 will be read but the mda will be ignored. All other PVs contain v1 metadata, and no auto-correct will be required. In fact, if we commit all PVs with ignored mdas first, we'll only have an inconsistent state when we start writing non-ignored PVs, and thus the chances we'll get an inconsistent state on disk is much less with the sorted method. Signed-off-by: Dave Wysochanski <dwysocha@redhat.com> |
||
|---|---|---|
| autoconf | ||
| daemons | ||
| doc | ||
| include | ||
| lib | ||
| libdm | ||
| liblvm | ||
| man | ||
| old-tests | ||
| po | ||
| scripts | ||
| test | ||
| tools | ||
| udev | ||
| configure | ||
| configure.in | ||
| COPYING | ||
| COPYING.LIB | ||
| INSTALL | ||
| make.tmpl.in | ||
| Makefile.in | ||
| README | ||
| VERSION | ||
| VERSION_DM | ||
| WHATS_NEW | ||
| WHATS_NEW_DM | ||
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://sources.redhat.com/pub/lvm2/ To access the CVS tree use: cvs -d :pserver:cvs@sources.redhat.com:/cvs/lvm2 login CVS password: cvs cvs -d :pserver:cvs@sources.redhat.com:/cvs/lvm2 co LVM2 Mailing list for general discussion related to LVM2: linux-lvm@redhat.com Subscribe from https://www.redhat.com/mailman/listinfo/linux-lvm Mailing list for LVM2 development, patches and commits: lvm-devel@redhat.com Subscribe from https://www.redhat.com/mailman/listinfo/linux-lvm 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