Bug 431714
| Summary: | RHEL5 cmirror tracker: issues with resync can cause it to be really slow | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Corey Marthaler <cmarthal> |
| Component: | cmirror | Assignee: | Jonathan Earl Brassow <jbrassow> |
| Status: | CLOSED WORKSFORME | QA Contact: | Cluster QE <mspqa-list> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 5.2 | CC: | agk, ccaulfie, dwysocha, heinzm, iannis, mbroz |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-04-07 22:05:35 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 432109 | ||
| Bug Blocks: | |||
|
Description
Corey Marthaler
2008-02-06 16:55:23 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release. Actually this appears to be happening more often.
I've also seen a case where after the resync, it gets stuck:
[root@grant-03 ~]# lvs
LV VG Attr LSize Origin Snap% Move Log
Copy% Convert
LogVol00 VolGroup00 -wi-ao 72.44G
LogVol01 VolGroup00 -wi-ao 1.94G
resync_nosync mirror_sanity mwi-a- 2.00G
resync_nosync_mlog 100.00
resync_regular mirror_sanity mwi-a- 2.00G
resync_regular_mlog 10.55
[root@grant-03 ~]# lvs
LV VG Attr LSize Origin Snap% Move Log
Copy% Convert
LogVol00 VolGroup00 -wi-ao 72.44G
LogVol01 VolGroup00 -wi-ao 1.94G
resync_nosync mirror_sanity mwi-a- 2.00G
resync_nosync_mlog 100.00
resync_regular mirror_sanity mwi-a- 2.00G
resync_regular_mlog 10.55
[root@grant-03 ~]# lvs
LV VG Attr LSize Origin Snap% Move Log
Copy% Convert
LogVol00 VolGroup00 -wi-ao 72.44G
LogVol01 VolGroup00 -wi-ao 1.94G
resync_nosync mirror_sanity mwi-a- 2.00G
resync_nosync_mlog 100.00
resync_regular mirror_sanity mwi-a- 2.00G
resync_regular_mlog 10.55
I'll attempt this with single node mirroring to see if this is a base lvm issue. I haven't hit this with single node mirrors in over 80 iterations in a row of this test case. That said, the "after 30 sec" sync percent is rarely 3X as big as the "after 10 sec" sync percent, and sometimes just barely larger. Having reproduced the case where the resync gets stuck (in comment #2) I'm going to open a new bug for that and leave this one for the fact that resync can be really slow and cause funky "invalid header" messages. My last checkin should improve the throughput of the resync I/O and nominal I/O. While it should be a big improvement, I would still expect nominal I/O to be pretty slow during the process. This appears to be fixed as well, however like the other issues marked modified, I eventually hit the 'cpg_mcast_joined error: 9' (bz 432109) message which causes testing to fail, so I can't be positive that issues like this can be marked verified. Hit 432109 again while attempting to verify this issue. Untouched for almost 3 years: Are there still issues, or can this be closed? Closing due to inactivity. Will reopen if seen again. |