Bug 1827220 - sanlock direct dump will not dump for start offset with unused record
Summary: sanlock direct dump will not dump for start offset with unused record
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: sanlock
Version: 8.1
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: rc
: 8.0
Assignee: David Teigland
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-04-23 13:08 UTC by Amit Bawer
Modified: 2020-11-04 02:14 UTC (History)
5 users (show)

Fixed In Version: sanlock-3.8.1-1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-11-04 02:14:39 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2020:4595 0 None None None 2020-11-04 02:14:49 UTC

Description Amit Bawer 2020-04-23 13:08:39 UTC
Description of problem:

Tried the following on RHEV block storage domain:

Dumping 102MB from 0 offset (returns nothing):

# sanlock direct dump leases:0:106954752

Dumping 102MB from 1MB offset:

# sanlock direct dump leases:1048576:106954752
  offset                            lockspace                                         resource  timestamp  own  gen lver
00000000 f7bf4ac4-1fda-4788-af10-20380ff13a6c                                              SDM 0000000000 0001 0001 1
104857600 f7bf4ac4-1fda-4788-af10-20380ff13a6c             bc00ab08-30fe-418b-9103-8ed02a40c270 0000000000 0000 0000 0
105906176 f7bf4ac4-1fda-4788-af10-20380ff13a6c             1d5f122f-4796-436c-aa38-c3f96635fc03 0000000000 0000 0000 0

This means dump will not be done if started from 0 offset where there is no record (RHEV SDM record is on the next 1MB offset).


Version-Release number of selected component (if applicable):

sanlock-3.8.0-2.el8.x86_64
sanlock-lib-3.8.0-2.el8.x86_64


How reproducible: 100%


Steps to Reproduce:

1. Create RHEV block storage domain
2. cd on RHEV host storage path: /rhev/data-center/<cluster uid>/<sd uid>/dom_md/
2. Run on host: sanlock direct dump leases:0:106954752 (no leases data)
3. Run on host: sanlock direct dump leases:1048576:106954752 (leases data)

Actual results: 

No dumped data for starting offset 0 when record is unused.


Expected results:

Sanlock should dump what it finds in the specified offset:size range instead of trying to bail out as soon as possible.


Additional info:

Comment 1 Nir Soffer 2020-04-23 13:16:48 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.

Comment 2 David Teigland 2020-04-23 20:36:56 UTC
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>.

Comment 3 David Teigland 2020-04-23 20:41:43 UTC
[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

Comment 7 Corey Marthaler 2020-09-14 18:51:50 UTC
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

Comment 10 errata-xmlrpc 2020-11-04 02:14:39 UTC
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


Note You need to log in before you can comment on or make changes to this bug.