Red Hat Bugzilla – Bug 1552070
Unable to set VDO writepolicy to auto
Last modified: 2018-06-20 23:34:49 EDT
+++ This bug was initially created as a clone of Bug #1552063 +++ Description of problem: ----------------------- Using gdeploy,unable to set the writePolicy of VDO volume to 'auto'. Gdeploy allows the value of 'sync' & 'async' for writePolicy Version-Release number of selected component (if applicable): -------------------------------------------------------------- gdeploy-2.0.2-22.el7rhgs How reproducible: ----------------- Always Steps to Reproduce: -------------------- 1. Create a gdeploy conf file to create VDO volume and set the writePolicy to auto Actual results: --------------- gdeploy fails to set the writePolicy as 'auto' Expected results: ----------------- gdeploy should allow setting the value of writePolicy as 'auto' Additional info: ---------------- Here is the sample config file [hosts] 10.70.36.244 [vdo] action=create devices=sde names=vdovol_test logicalsize=18T writepolicy=auto slabsize=32G emulate512=enabled Here is the console output: # gdeploy -c vdocreate.conf PLAY [gluster_servers] ******************************************************************************************************************************************************************************************** TASK [Create VDO with specified size] ***************************************************************************************************************************************************************************** failed: [10.70.36.244] (item={u'disk': u'/dev/sde', u'logicalsize': u'18T', u'name': u'vdovol_test'}) => {"changed": false, "item": {"disk": "/dev/sde", "logicalsize": "18T", "name": "vdovol_test"}, "msg": "value of writepolicy must be one of: sync,async, got: auto"} to retry, use: --limit @/tmp/tmpVnBih0/vdo-create.retry PLAY RECAP ******************************************************************************************************************************************************************************************************** 10.70.36.244 : ok=0 changed=0 unreachable=0 failed=1
sas, which version of VDO are you using? As per vdo documentation they allow only sync and async. ============ --writePolicy={ sync | async } Specifies the write policy: sync Writes are acknowledged only after data is stably written. This is the default policy. This policy is not supported if the underlying storage is not also synchronous. async Writes are acknowledged after data has been cached for writing to stable storage. Data which has not been flushed is not guaranteed to persist in this mode. ======== [root@localhost ~]# rpm -qa | grep vdo kmod-kvdo-6.1.0.55-9.el7.x86_64 vdo-6.1.0.55-10.x86_64
The latest VDO supports the writePolicy 'auto' vdo versions are below: kmod-kvdo-6.1.0.153-15.el7.x86_64 vdo-6.1.0.149-16.x86_64 <snip_from_man_vdo> --writePolicy={ sync | async | auto } Specifies the write policy: sync Writes are acknowledged only after data is stably written. This policy is not supported if the underlying storage is not also synchronous. async Writes are acknowledged after data has been cached for writing to stable storage. Data which has not been flushed is not guaranteed to persist in this mode. auto VDO will check the storage device and determine whether it supports flushes. If it does, VDO will run in async mode, otherwise it will run in sync mode. This is the default. </snip_from_man_vdo>
sas, this bug should be fixed in Ansible 2.5. This is a bug in the vdo ansible module itself. Which is part of Ansible now. We are removing the ansible module from gdeploy. Which is addressed here: https://github.com/gluster/gdeploy/pull/495/commits/38e5c041fd64df4 And Devyani will be adding Ansible 2.5 as the dependency in the next build.
Tested with gdeploy-2.0.2-26.el7rhgs. writePolicy now could be set to 'auto'
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/RHEA-2018:1958