RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1855804 - lvmvdo(7) manpage bugs (manpage needs refinement)
Summary: lvmvdo(7) manpage bugs (manpage needs refinement)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: lvm2
Version: 8.3
Hardware: Unspecified
OS: Unspecified
urgent
medium
Target Milestone: rc
: 8.0
Assignee: Zdenek Kabelac
QA Contact: cluster-qe@redhat.com
Marek Suchánek
URL:
Whiteboard:
Depends On:
Blocks: 1895081
TreeView+ depends on / blocked
 
Reported: 2020-07-10 14:37 UTC by Petr Beranek
Modified: 2021-09-07 11:51 UTC (History)
13 users (show)

Fixed In Version: lvm2-2.03.11-0.3.20201210git9fe7aba.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1895081 (view as bug list)
Environment:
Last Closed: 2021-05-18 15:01:53 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Petr Beranek 2020-07-10 14:37:48 UTC
Description of problem:

The current lvmvdo(7) manpage contains inconsistencies, incorrect grammar, some words are missing, some sections are not very informative and seem to be a stub. It is also missing some important information (it is tracked in separate bug https://bugzilla.redhat.com/show_bug.cgi?id=1849009). The overall effect decreases user experience and confidence in our product.


Found problems (problems are grouped by chapter names if possible):

1. inconsistent chapter names: Some chapter names are in all caps (e.g. NAME),
   some are not (e.g. VDO Terms).

NAME
2. It still contains word `EXPERIMENTAL' even though it should become fully 
   supported product in 8.3.

DESCRIPTION
3. What does the abbreviation `LBA' mean? (is it `Logical block address'?). 
   We should at least define it first, and than use it, if necessary. There
   is sometimes `LBA', sometimes `logical block addresses'. Let's make it 
   consistent and clear (prevent users to guess it for the context).

VDO Terms ( -> VDO TERMS )
4. VDOPoolLV: Is there a missing word "size" in the following sentence?:
   "maintains virtual for LV(s) stored in attached VDO data LV [...]"
5. Shouldn't sentences begin with capital letter? Some sentences end with 
   period, some don't. Make it consistent.

VDO Usage ( -> VDO USAGE )
6. wrong numbering of subchapters

subchapter 1. Create VDOPoolLV with VDOLV
7. incorrect grammar, e.g. "Create  an VDOPoolLV that will holds [...]"
                                     ^                         ^
8. In the last sentence "When  the name of VDOPoolLV is not specified, it
   tales name from sequence of vpool0 [...]" the verb "tales" seems strange. 
   Does it make sense to native speakers? Shouldn't we reword it?
9. There is missing information about user's responsibility for reclaiming 
   unused storage blocks (tracked in https://bugzilla.redhat.com/show_bug.cgi?id=1849009; possible corner case https://bugzilla.redhat.com/show_bug.cgi?id=1846036).

subchapter 2. Create VDOPoolLV and convert existing LV into VDODataLV
10. Is there a missing word "be" in the following sentence?:
    "When the  virtual  size  is  not specified,  it  will  set to the maximum 
    size [...]"
11. Example `lvconvert --vdopool VG/VDOPoolLV' - shouldn't it be 
    `VG/ExistingLV' instead of the `VG/VDOPoolLV'?

VDO Topics ( -> VDO TOPICS )
12. wrong numbering of subchapters
13. Subchapters do not seem very informative, seem more like a stub. At least
    in the subchapter `1. Stacking VDO' user deserves more elaborated 
    information about supported combinations and possible pitfalls.
14. missing section about TRIM/DISCARD behavior, its solutions and recommended 
    practices

subchapter 3. Caching VDODataLV, VDOPoolLV
15. missing closing parenthesis



Version-Release number of selected component (if applicable):
lvm2-2.03.09-3.el8.x86_64 (RHEL8.3)

Comment 1 Juraj Hrdlica 2020-07-29 14:08:30 UTC
Problems with examples (***suggestions*** can be found on the same line as the problem):

3. Change default setting used for creating VDOPoolLV
       Example
       # cat <<EOF > vdo.profile    ***cat <<EOF > /etc/lvm/profile/vdo.profile***
       allocation {
            vdo_use_compression=1
            vdo_use_deduplication=1
            vdo_use_metadata_hints=1
            vdo_minimum_io_size=4096
            vdo_block_map_cache_size_mb=128
            vdo_block_map_period=16380
            vdo_check_point_frequency=0
            vdo_use_sparse_index=0
            vdo_index_memory_size_mb=256
            vdo_slab_size_mb=2048
            vdo_ack_threads=1
            vdo_bio_threads=1
            vdo_bio_rotation=64
            vdo_cpu_threads=2
            vdo_hash_zone_threads=1
            vdo_logical_threads=1
            vdo_physical_threads=1
            vdo_write_policy="auto"
            vdo_max_discard=1
       }
       EOF

       # lvcreate --vdo -L10G --metadataprofile vdo.profile vg/vdopool0    ***lvcreate --vdo -L10G --metadataprofile vdo vg/vdopool0***
       # lvcreate --vdo -L10G --config 'allocation/vdo_cpu_threads=4' vg/vdopool1

4. Checking usage of VDOPoolLV
       Example
       # lvcreate --type vdo -L10G -V20G -n vdo0 vg/vdopool0
       # mkfs.ext4 -E nodiscard /dev/vg/vdo0
       # lvs -a vg

         LV               VG Attr       LSize  Pool     Origin Data%
         vdo0             vg vwi-a-v--- 20.00g vdopool0        0.01
         vdopool0         vg dwi-ao---- 10.00g                 30.16
         [vdopool0_vdata] vg Dwi-ao---- 10.00g

       # vdostats --all /dev/mapper/vg-vdopool0    ***vdostats --all /dev/mapper/vg-vdopool0-vpool***
       /dev/mapper/vg-vdopool0 :
         version                             : 30
         release version                     : 133524
         data blocks used                    : 79
         ...

3. Caching VDOLV
       Example
       # lvcreate -L 5G -V 10G -n vdo1 vg/vpool    ***lvcreate --type vdo -L 5G -V 10G -n vdo1 vg/vpool***
       # lvcreate --type cache-pool -L 1G -n cpool vg
       # lvconvert --cache --cachepool vg/cpool vg/vdo1
       # lvconvert --uncache vg/vdo1

Comment 2 Zdenek Kabelac 2020-08-19 14:25:43 UTC
Pushed updates for man pages:

https://www.redhat.com/archives/lvm-devel/2020-August/msg00013.html

Mostly fixes reported issue from BZ description - although some capital
letters remained to be more look a like to other man pages
(as there is no real strick guide how to use them)

Comment 1 need another look - the thing to note is - that it's
been rather illustratively written - but if it doesn't
really work - then it might some polishing and doc enhancements.

Comment 4 Zdenek Kabelac 2020-09-09 13:21:09 UTC
Upstreamed remaining issues from comment 1:

https://www.redhat.com/archives/lvm-devel/2020-September/msg00045.html

with few more 'configure' based updates.
https://www.redhat.com/archives/lvm-devel/2020-September/msg00045.html


If there will be chance to squeeze them into a release - these patches have zero risk.

Comment 7 Petr Beranek 2020-10-08 10:09:27 UTC
Fixes referenced in comment #2 and comment #4 looks good.

However I seems issues num. 3, 4, 5, 11 and 13 from the bug description haven't been fixed. Could you, please, provide a reason why they are not fixed?

Comment 8 Roman Bednář 2020-10-19 13:51:55 UTC
'man lvmvdo' states that kvdo (refers to kmod-kvdo package) is required, however that's not completely true because without 'vdo' package lvcreate fails:

# rpm -qa  |grep vdo
kmod-kvdo-6.2.4.14-74.el8.x86_64

# lvcreate --type vdo -L10G -V100G -n vdovol vg
  /usr/bin/vdoformat: execvp failed: No such file or directory
  Command /usr/bin/vdoformat failed.
  Cannot format VDO pool volume vg/vpool0.

# yum install -y vdo
...

# lvcreate --type vdo -L10G -V100G -n vdovol vg
    The VDO volume can address 6 GB in 3 data slabs, each 2 GB.
    It can grow to address at most 16 TB of physical storage in 8192 slabs.
    If a larger maximum size might be needed, use bigger slabs.
  Logical volume "vdovol" created.

Comment 9 Marek Suchánek 2020-10-21 11:18:30 UTC
If you'd like the man page to be reviewed by a technical writer, let me know.

Comment 11 Zdenek Kabelac 2020-11-03 15:43:30 UTC
Pushed update: https://www.redhat.com/archives/lvm-devel/2020-November/msg00000.html

3,4,5 rephrased
11 changed
13 added more info

Also added 2 new chapters about memory and space usage.

Fixed some cpool & vpool names in examples

More condensed page by dropping unneded empty lines.

Comment 14 Petr Beranek 2020-11-10 12:27:06 UTC
Due to impediments in delivery of related test compose I'm increasing ITM to 5.

Comment 15 Petr Beranek 2020-11-12 16:49:41 UTC
Tested on lvm2-2.03.11-0.2.20201103git8801a86.el8.x86_64; build RHEL-8.4.0-20201110.d.3:

* Almost all the problems were fixed - unfortunately the last problem from comment #1 (3. Caching VDOLV) is still not fixed.
* The overall quality of the manpage seems to me greatly improved.
* Marking this bug as verified:tested and passing the manpage for review by msuchane.

Comment 21 Petr Beranek 2020-12-03 16:27:22 UTC
pkg: lvm2-2.03.11-0.2.20201103git8801a86.el8.x86_64
distro: RHEL-8.4.0-20201201.n.1

Unfortunately, despite of fixes and overall improvements not all the issues are fixed:

* last problem from comment #1 (3. Caching VDOLV) is still not fixed,
* patch mentioned in comment #20 with language and style edits doesn't seem to be applied,
* ambiguities mentioned in review by Marek Suchanek [0] are not resolved.

Therefore I cannot consider this bug as fixed.


[0] https://docs.google.com/document/d/1iHTUXzeAEZK1eO81uAEOFickh2kMgG5IiALqq6oJWvw/edit

Comment 23 Zdenek Kabelac 2020-12-03 22:30:08 UTC
Upstream patch:  https://www.redhat.com/archives/lvm-devel/2020-December/msg00000.html
likely missed inclusion into build?

Comment 24 Zdenek Kabelac 2020-12-08 19:53:15 UTC
Pushed some more tunings for comment 21.

https://www.redhat.com/archives/lvm-devel/2020-December/msg00002.html

Comment 32 errata-xmlrpc 2021-05-18 15:01:53 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 (lvm2 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-2021:1659


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