Bug 1827220
| Summary: | sanlock direct dump will not dump for start offset with unused record | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Amit Bawer <abawer> |
| Component: | sanlock | Assignee: | David Teigland <teigland> |
| Status: | CLOSED ERRATA | QA Contact: | cluster-qe <cluster-qe> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 8.1 | CC: | agk, cluster-maint, cmarthal, nsoffer, rhandlin |
| Target Milestone: | rc | ||
| Target Release: | 8.0 | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | sanlock-3.8.1-1 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-11-04 02:14:39 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
Amit Bawer
2020-04-23 13:08:39 UTC
RHV wants to use "sanlock direct dump" for dumping lockspace and resources for soserport and for debugging purposes. We can workaround this issue by starting to dump from the known offset of the SDM lease (always at 1MiB). We would like to have this fixed in 8.3. https://pagure.io/sanlock/c/807e74a10a118d0b744b067fee7c2a741f95bce1?branch=master sanlock: fix direct dump with offset For direct dump <path>:<offset>:<size> the dump is meant to continue reading/reporting for the entire range. If the sector_size/align_size were not at <offset> the dump would stop. Fix this by searching through the range for sector_size/align_size before beginning the real dump. Accept the M (MB) suffix on offset and size. Fix the printed offset of structures so that it is always relative to the start of the disk (it had been relative to the <offset>.) The problem was that the dump would quit when it didn't find sector_size/align_size at <offset>. Another work-around for existing versions is to specify -Z <sector_size> -A <align_size> as the last options on the command line, i.e.g sanlock direct dump /dev/foo:<offset>:<size> -Z <sector_size> -A <align_size>. [root@null-01 src]# sanlock direct init -r LS:R1:/dev/loop6:6M init done 0 [root@null-01 src]# sanlock direct dump /dev/loop6 offset lockspace resource timestamp own gen lver [root@null-01 src]# sanlock direct dump /dev/loop6:0:8M offset lockspace resource timestamp own gen lver 06291456 LS R1 0000000000 0000 0000 0 [root@null-01 src]# sanlock direct dump /dev/loop6:6M:1M offset lockspace resource timestamp own gen lver 06291456 LS R1 0000000000 0000 0000 0 Fix verified in the latest rpms. sanlock-3.8.2-1.el8 BUILT: Mon Aug 10 12:12:49 CDT 2020 sanlock-lib-3.8.2-1.el8 BUILT: Mon Aug 10 12:12:49 CDT 2020 kernel-4.18.0-234.el8 BUILT: Thu Aug 20 12:01:26 CDT 2020 lvm2-2.03.09-5.el8 BUILT: Wed Aug 12 15:51:50 CDT 2020 lvm2-libs-2.03.09-5.el8 BUILT: Wed Aug 12 15:51:50 CDT 2020 [root@hayes-01 ~]# sanlock status daemon de5af774-c1b3-4202-b94e-5d0bfa9250cb.hayes-01.la p -1 helper p -1 listener p -1 status s LS:1:/dev/snapper/sanlock_monitor:0 [root@hayes-01 ~]# sanlock gets -h 1 s LS:1:/dev/snapper/sanlock_monitor:0 h 1 gen 1 timestamp 246994 LIVE [root@hayes-01 ~]# sanlock direct dump /dev/snapper/sanlock_monitor:0:1M offset lockspace resource timestamp own gen lver 00000000 LS de5af774-c1b3-4202-b94e-5d0bfa9250cb.hayes-01.l 0000246967 0001 0001 [root@hayes-01 ~]# sanlock direct dump /dev/snapper/sanlock_monitor:0:10M offset lockspace resource timestamp own gen lver 00000000 LS de5af774-c1b3-4202-b94e-5d0bfa9250cb.hayes-01.l 0000246972 0001 0001 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 (sanlock bug fix and enhancement update), 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://access.redhat.com/errata/RHBA-2020:4595 |