Bug 1358532
| Summary: | raid6 --nosync flag create regression | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Corey Marthaler <cmarthal> |
| Component: | lvm2 | Assignee: | Heinz Mauelshagen <heinzm> |
| lvm2 sub component: | Mirroring and RAID | QA Contact: | cluster-qe <cluster-qe> |
| Status: | CLOSED ERRATA | Docs Contact: | |
| Severity: | low | ||
| Priority: | unspecified | CC: | agk, heinzm, jbrassow, msnitzer, prajnoha, prockai, zkabelac |
| Version: | 7.3 | Keywords: | Regression |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | lvm2-2.02.163-1.el7 | Doc Type: | Bug Fix |
| Doc Text: |
Cause:
dm-raid needs to reject the 'nosync' flag on raid6 LVs, because the MD raid6 personality used to drive such RaidLVs does read-modify-write and needs a full initial synchronization to work properly.
Consequence:
Without initial synchronization there'll be potential data loss in case of device failures, because user data will be reconstructed from non-initialized parity blocks
(P-/Q-Syndrome blocks).
Fix:
Prohibit the 'nosync' flag in the dm-raid target on raid6 mappings as already done in upstream/RHEL7
Result:
Userspace regression as of $Subject of this bz.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-11-04 04:16:04 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Corey Marthaler
2016-07-20 23:02:48 UTC
Neil Brown emphasized last year that a raid6 array has to be always initially synced to ensure proper P+Q syndromes or there'll be a potential for data corruption in degraded arrays. Clarifying if that's correct. If so, I'll add a patch to lvm2 to ignore the nosync flag on raid6. Due to following statement from the current maintainer, that issue got addressed. Preparing dm-raid kernel patch to allow for raid6 nosync flag to be processed. Hi, Since 2014, raid6 supports read-modify-write, so no initial sync could make data lost. Thanks, Shaohua 2016-08-03 17:41 GMT-07:00 Heinz Mauelshagen <heinzm>: > > Hi Shaohua, > > Neil told me last year, that raid6 P+Q syndromes needs to be created, i.e. > the array always initially synchronized. > > Is that true and raid6 may cause data corruption in case of no initial sync > or does it always recreate both P+Q syndromes on a stripe update? > > Heinz > (In reply to Heinz Mauelshagen from comment #4) > Due to following statement from the current maintainer, > that issue got addressed. Preparing dm-raid kernel patch to allow > for raid6 nosync flag to be processed. I misread Shaoha's comment, thus Neil's statement is still correct and we need to reject the 'nosync' flag for raid6 as is in order to compute correct data in case of 1-2 device failures. This means that any kernel supporting MD raid6 read-modify-write used to drive an lvm nosync raid6 LV is potentially subject to data loss in case of a device failure unless e.g. "lvchange --resync RaidLV" was run successfully. LVM2 userspace lvcreate command needs enhancement to fail early on 'nosync' requested for raid6 LVs and provide a failure message rather than failing late in the kernel. > > > > Hi, > Since 2014, raid6 supports read-modify-write, so no initial sync could > make data lost. > > Thanks, > Shaohua > > 2016-08-03 17:41 GMT-07:00 Heinz Mauelshagen <heinzm>: > > > > Hi Shaohua, > > > > Neil told me last year, that raid6 P+Q syndromes needs to be created, i.e. > > the array always initially synchronized. > > > > Is that true and raid6 may cause data corruption in case of no initial sync > > or does it always recreate both P+Q syndromes on a stripe update? > > > > Heinz > > LVM2 upstream commit 7d6cf12554b0b6cbbee9db2f4da9439d6492a2b3 to reject nosync option on raid6 creation including manual page update/fix and test script. Verified that --nosync is no longer allowed w/ raid6. [root@host-083 ~]# lvcreate --nosync --type raid6 -n six -L 2G test Using default stripesize 64.00 KiB. nosync option prohibited on RAID6 Run `lvcreate --help' for more information. 3.10.0-489.el7.x86_64 lvm2-2.02.163-1.el7 BUILT: Wed Aug 10 06:53:21 CDT 2016 lvm2-libs-2.02.163-1.el7 BUILT: Wed Aug 10 06:53:21 CDT 2016 lvm2-cluster-2.02.163-1.el7 BUILT: Wed Aug 10 06:53:21 CDT 2016 device-mapper-1.02.133-1.el7 BUILT: Wed Aug 10 06:53:21 CDT 2016 device-mapper-libs-1.02.133-1.el7 BUILT: Wed Aug 10 06:53:21 CDT 2016 device-mapper-event-1.02.133-1.el7 BUILT: Wed Aug 10 06:53:21 CDT 2016 device-mapper-event-libs-1.02.133-1.el7 BUILT: Wed Aug 10 06:53:21 CDT 2016 device-mapper-persistent-data-0.6.3-1.el7 BUILT: Fri Jul 22 05:29:13 CDT 2016 cmirror-2.02.163-1.el7 BUILT: Wed Aug 10 06:53:21 CDT 2016 sanlock-3.4.0-1.el7 BUILT: Fri Jun 10 11:41:03 CDT 2016 sanlock-lib-3.4.0-1.el7 BUILT: Fri Jun 10 11:41:03 CDT 2016 lvm2-lockd-2.02.163-1.el7 BUILT: Wed Aug 10 06:53:21 CDT 2016 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-1445.html |