Bug 1565311
| Summary: | vdo status command shows index is online after index fails to start | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Bryan Gurney <bgurney> | |
| Component: | kmod-kvdo | Assignee: | Thomas Jaskiewicz <tjaskiew> | |
| Status: | CLOSED ERRATA | QA Contact: | Jakub Krysl <jkrysl> | |
| Severity: | unspecified | Docs Contact: | ||
| Priority: | high | |||
| Version: | 7.5 | CC: | awalsh, bgurney, jkrysl, limershe, rhandlin, vdo-qe | |
| Target Milestone: | rc | Keywords: | ZStream | |
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | 6.1.1.60 | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1578421 (view as bug list) | Environment: | ||
| Last Closed: | 2018-10-30 09:39:31 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: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1578421 | |||
|
Description
Bryan Gurney
2018-04-09 20:03:36 UTC
I did try to make an 8 GB scsi_debug device with the "opts=0x2" option, which configures the device to return a medium error on reads of sector 0x1234. My test system has 32 GB of RAM, so I ran the following command: # modprobe scsi_debug dev_size_mb=8192 opts=0x2 ...which created an 8 GB "scsi_debug" device appearing as /dev/sdd. - Create a VDO volume on this device. (There will be about 4 GB of physical space usable, since the scsi_debug device is so small; make the logical size 40 GB.) # vdo create --name=scsidebugvdo --device=/dev/sdd --vdoLogicalSize=40G --verbose - Create an XFS filesystem on this device. # mkfs.xfs -K /dev/mapper/scsidebugvdo # mount -o discard /dev/mapper/scsidebugvdo /mnt/scsidebugvdo/ - Start copying and deleting data. I chose two datasets: a high-dedupe 1 GB file, and a 2 GB directory of documents. I kept copying the files in, and then removing the files and/or directories, which triggered XFS to send discards for the blocks vacated after the removal. Apr 10 16:47:29 charitable-view systemd-logind: New session 244 of user root. Apr 10 16:47:29 charitable-view systemd: Started Session 244 of user root. Apr 10 16:47:29 charitable-view systemd: Starting Session 244 of user root. Apr 10 16:47:41 charitable-view kernel: sd 10:0:0:0: [sdd] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE Apr 10 16:47:41 charitable-view kernel: sd 10:0:0:0: [sdd] Sense Key : Medium Error [current] Apr 10 16:47:41 charitable-view kernel: sd 10:0:0:0: [sdd] Add. Sense: Unrecovered read error Apr 10 16:47:41 charitable-view kernel: sd 10:0:0:0: [sdd] CDB: Read(10) 28 00 00 00 12 18 00 00 40 00 Apr 10 16:47:41 charitable-view kernel: blk_update_request: critical medium error, dev sdd, sector 4632 Apr 10 16:47:41 charitable-view kernel: uds: kvdo12:reader: error reading physical page 72: Unknown error 61 (61) Apr 10 16:47:41 charitable-view kernel: uds: kvdo12:reader: Error reading page 72 from volume Apr 10 16:47:49 charitable-view systemd-logind: Removed session 244. Apr 10 16:47:50 charitable-view kernel: uds: kvdo12:writer: Discarding saved open chapter Apr 10 16:47:53 charitable-view kernel: uds: vdostats: getBaseContext() failed.: UDS Error: UDS library context is disabled (1029) Apr 10 16:47:53 charitable-view kernel: kvdo12:vdostats: Error reading index stats: UDS Error: UDS library context is disabled (1029) Apr 10 16:47:53 charitable-view kernel: uds: vdostats: getBaseContext() failed: UDS Error: UDS library context is disabled (1029) Apr 10 16:47:53 charitable-view kernel: kvdo12:vdostats: Error reading context stats: UDS Error: UDS library context is disabled (1029) I saw the "getBaseContext()" errors when I ran "vdostats --verbose". However, I did still see the sysfs directory for the index. This isn't enti rely unexpected, as the original scenario for this bug was during VDO volume startup, and this scenario is well after startup has completed, but d uring normal operation. Does QA need any more info? No thanks, I will try some reproducers and if they fail to reproduce, will do just SanityOnly. Tested on: RHEL-7.6-20180626.0 kernel-3.10.0-915.el7 kmod-vdo-6.1.1.99-1.el7 vdo-6.1.1.99-2.el7 I could not get the index to failed state as vdo managed to rebuild the index each time. Regression testing passed. 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://access.redhat.com/errata/RHBA-2018:3094 |