Bug 1811988 - [vdo] Replace older method of modifying VDO max_discard_size with newer VDO option
Summary: [vdo] Replace older method of modifying VDO max_discard_size with newer VDO o...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat Storage
Component: rhhi
Version: rhhiv-1.8
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
: RHHI-V 1.8
Assignee: Gobinda Das
QA Contact: SATHEESARAN
URL:
Whiteboard:
Depends On: 1811989 1811991
Blocks: RHHI-V-1.8-Engineering-Inflight-BZs
TreeView+ depends on / blocked
 
Reported: 2020-03-10 10:38 UTC by SATHEESARAN
Modified: 2020-08-04 14:51 UTC (History)
2 users (show)

Fixed In Version: cockpit-ovirt-0.14.3-1.el8ev
Doc Type: No Doc Update
Doc Text:
Clone Of:
: 1811989 1811991 (view as bug list)
Environment:
Last Closed: 2020-08-04 14:51:37 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2020:3314 0 None None None 2020-08-04 14:51:55 UTC

Description SATHEESARAN 2020-03-10 10:38:43 UTC
Description of problem:
-----------------------
RHHI-V uses VDO for dedupe & compression functionality. On top of VDO, thin LVs are created. In this combination, we found a problem (BZ 1600156), where discards weren't passed down, because of vdo_discard_sector(size) is smaller than thinpool's. To avoid that RHHI deployment at cockpit made custom changes to VDO systemd unit file to have the following:
---
ExecStartPre=/bin/sh -c "echo 4096 > /sys/kvdo/max_discard_sectors"
---
in /usr/lib/systemd/system/vdo.service.

But as per VDO instructions, with kernel > 4.6 (i.e) RHEL 8 kernel && from VDO 6.2, VDO exposes the option 'maxDiscardSize' per VDO volume.

RHHI-V 1.8 will be using RHEL 8.2 hosts, with RHV 4.4, with VDO 6.2.z.
This change needs to be updated in cockpit-wizard and that's the reason for existence of this bug

Version-Release number of selected component (if applicable):
-------------------------------------------------------------
kmod-kvdo-6.2.2.117-64.el8.x86_64
vdo-6.2.2.117-13.el8.x86_64
Kernel - 4.18.0-187.el8.x86_64
cockpit-ovirt-dashboard-0.14.1-1.el8ev.noarch0

How reproducible:
-----------------
Always

Steps to Reproduce:
-------------------
1. Start with RHHI-V deployment with VDO

Actual results:
---------------
systemd unit file for VDO (/usr/lib/systemd/system/vdo.service) has the following:
---
ExecStartPre=/bin/sh -c "echo 4096 > /sys/kvdo/max_discard_sectors"
---

Expected results:
-----------------
VDO option maxDiscardSize should be used instead

Additional info:
----------------
To bring about this change 2 places needs change
1. gluster-ansible-infra : 
    change-1: Remove the lines that customizes systemd VDO unit file
    change-2: Update the VDO options set on the newly created VDO volume
    Add the new option - 'maxDiscardSize' in /etc/ansible/roles/gluster.infra/roles/backend_setup/tasks/vdo_create.yml

2. cockpit-wizard: to set up the new VDO option while creating.

1. gluster-ansible changes
---------------------------
1. Remove the line from '/etc/ansible/roles/gluster.infra/roles/backend_setup/tasks/main.yml'
<snip>
# When VDO is used, upon creation and activation of thinpools discard is not
# possible, because of the misaligned discard size between thinpool and VDO.
# Warning: kernel: device-mapper: thin: Data device (dm-N) max discard sectors
# smaller than a block: Disabling discard passdown. Is displayed.
# To overcome this, add command in service file to set
# /sys/kvdo/max_discard_sectors to 4096 and restart vdo service

- name: Update vdo service to set /sys/kvdo/max_discard_sectors to 4096
  blockinfile:
     path: /usr/lib/systemd/system/vdo.service
     insertbefore: '^ExecStart='
     marker: "#{mark} ANSIBLE MANAGED BLOCK - DO NOT EDIT THIS LINE"
     block: |
        ExecStartPre=/sbin/modprobe -a uds
        ExecStartPre=/sbin/modprobe -a kvdo
        ExecStartPre=/bin/sh -c "echo 4096 > /sys/kvdo/max_discard_sectors"
  when: gluster_infra_vdo is defined
  tags:
    - vdocreate
</snip>

update required
<snip>
- name: Update vdo service to set /sys/kvdo/max_discard_sectors to 4096
  blockinfile:
     path: /usr/lib/systemd/system/vdo.service
     insertbefore: '^ExecStart='
     marker: "#{mark} ANSIBLE MANAGED BLOCK - DO NOT EDIT THIS LINE"
     block: |
        ExecStartPre=/sbin/modprobe -a uds
        ExecStartPre=/sbin/modprobe -a kvdo
  when: gluster_infra_vdo is defined
  tags:
    - vdocreate
</snip>

2. Update the VDO option 'maxDiscardSize' in /etc/ansible/roles/gluster.infra/roles/backend_setup/tasks/vdo_create.yml

cockpit-wizard change
----------------------
Add a new VDO volume option --maxDiscardSize=16M when new VDO volume is created

Comment 1 SATHEESARAN 2020-03-10 10:51:43 UTC
Following example explains the usage of VDO option 'maxDiscardSize'

[root@ ~]# vdo create -n vdo_sdd --vdoLogicalSize=1T --vdoSlabSize=32G --device /dev/sdd --maxDiscardSize=16M
Creating VDO vdo_sdd
      The VDO volume can address 1 TB in 58 data slabs, each 32 GB.
      It can grow to address at most 256 TB of physical storage in 8192 slabs.
Starting VDO vdo_sdd
Starting compression on VDO vdo_sdd
VDO instance 2 volume is ready at /dev/mapper/vdo_sdd

[root@ ~]# vdo status -n vdo_sdd | grep -i 'discard size'
    Max discard size: 16M

[root@ ~]# dmsetup table | grep vdo_sdd
vdo_sdd: 0 2147483648 vdo V2 /dev/disk/by-id/scsi-3600304801a48610125f9a60819a7d829 488243200 4096 32768 16380 on auto vdo_sdd maxDiscard 4096 ack 1 bio 4 bioRotationInterval 64 cpu 2 hash 1 logical 1 physical 1

Comment 3 SATHEESARAN 2020-04-07 09:33:13 UTC

Tested with gluster-ansible-infra-1.0.4-7.el8 and cockpit-ovirt-dashboard-0.14.3
When role was execute, it no longer tries to add changes to vdo systemd unit file,
instead the per VDO volume option 'maxDiscardSize' is set to 16M

Comment 5 errata-xmlrpc 2020-08-04 14:51:37 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 (RHHI for Virtualization 1.8 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/RHEA-2020:3314


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