Description of problem: ----------------------- With RAID6 disktype, with diskcount & stripe-size available, the chunksize for LV thinpool creation is computed incorrectly. Version-Release number of selected component (if applicable): ------------------------------------------------------------- gdeploy-2.0.1-8.el7rhgs How reproducible: ----------------- Always Steps to Reproduce: ------------------- 1. Create config file as follows [disktype] raid6 [diskcount] 4 [stripesize] 256 [pv] action=create devices=vdb [vg1] action=create vgname=RHGS_vg1 pvname=vdb [lv] action=create vgname=RHGS_vg1 poolname=lvthinpool lvtype=thinpool poolmetadatasize=1MB size=20GB 2.Check for the chunksize of the LV thinpool Actual results: --------------- 'chunksize' is not the value that is expected. It should be the product of stripe-size and number of data disks Expected results: ------------------ 'chunksize' for LV thin pool creation should be the product of stripe-size and number of data disks
This bug is the blocker and needs to be fixed, as Grafton GA installation relies on the calculation of correct chunksize for optimal configuration as recommended in the RHGS Admin guide[1] [1] - https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3.1/html-single/Administration_Guide/index.html#Hardware_RAID This would also affect other RHGS installation as the creation of LV thinpool will use a wrong value for 'chunksize' attribute
https://github.com/gluster/gdeploy/commit/2455587e365c5e7 should resolve the issue. This bug was fixed in upstream as part of fix to: https://github.com/gluster/gdeploy/issues/251
As discussed in blocker triage meeting providing qa_ack.
Tested with gdeploy-2.0.1-9.el7rhgs and it failed verification, as the chunk size always remains to be at 1MB, irrespective of change in number of disks. The following config file was used: [root@dhcp37-196 ~]# cat hc.conf # A sample configuration file to setup ROBO [hosts] host1.lab.eng.blr.redhat.com [disktype] raid6 [diskcount] 8 [stripesize] 256 [pv] action=create devices=vdb [vg1] action=create vgname=RHGS_vg1 pvname=vdb [lv1] action=create vgname=RHGS_vg1 lvname=engine_lv lvtype=thick size=10GB mount=/rhgs/brick1 [lv2] action=create vgname=RHGS_vg1 poolname=lvthinpool lvtype=thinpool poolmetadatasize=10MB chunksize=1024k size=30GB [lv3] action=create lvname=lv_vmaddldisks poolname=lvthinpool vgname=RHGS_vg1 lvtype=thinlv mount=/rhgs/brick2 virtualsize=9GB Here is the chunksize as reported from lv: #lvs -o chunksize /dev/mapper/RHGS_vg1-lvthinpool Chunk 1.00m
I made a mistake as the chunksize is hardcoded in the config file and that made the chunksize remain the same for different disk count. Just noticed this issue. Let me retry verification having this hardcoded value removed
Tested again with gdeploy-2.0.1-9.el7rhgs and found that the chunksize is constant value of 192k for different diskcount values. Hence this bug failed QA verification Below is the config file used: [hosts] host.example.com [disktype] raid6 [diskcount] 4 [stripesize] 256 [pv] action=create devices=vdb [vg1] action=create vgname=RHGS_vg1 pvname=vdb [lv1] action=create vgname=RHGS_vg1 lvname=engine_lv lvtype=thick size=10GB mount=/rhgs/brick1 [lv2] action=create vgname=RHGS_vg1 poolname=lvthinpool lvtype=thinpool poolmetadatasize=10MB size=30GB [lv3] action=create lvname=lv_vmaddldisks poolname=lvthinpool vgname=RHGS_vg1 lvtype=thinlv mount=/rhgs/brick2 virtualsize=9GB # lvs -o chunksize /dev/mapper/RHGS_vg1-lvthinpool Chunk 192.00k
I checked the code [1] and as per the logic implemented it should return 256 * 4 i.e. 1024 k, not sure how are we arriving at 192k. I've asked Devyani to looking into it. [1] https://github.com/gluster/gdeploy/pull/260/files
sas, the cause for this bug is: We used to compute the chunksize in lv module and the required parameters were not accessible to modules hence it used to default to a value chosen by lvm. Now the chunksize computation is moved out of module to lv feature. And the chunksize is picked as param in the module. The changes are committed: https://github.com/gluster/gdeploy/commit/043d8448dc I tested with various values: 0. Specifying in the chunksize= variable within lv section. 1. Specifying diskcount and stripesize 2. Leaving to default (i.e not providing any in the config. [root@rhgs2 ~]# lvs -o chunk_size /dev/mapper/RHGS_vg1-lvthinpool Chunk 4.00m [root@rhgs2 ~]# lvs -o chunk_size /dev/mapper/RHGS_vg1-lvthinpool Chunk 40.00m [root@rhgs2 ~]# lvs -o chunk_size /dev/mapper/RHGS_vg1-lvthinpool Chunk 64.00k Results look good, request more testing.
(In reply to Sachidananda Urs from comment #11) > sas, the cause for this bug is: > > We used to compute the chunksize in lv module and the required parameters > were not accessible to modules hence it used to default to a value chosen by > lvm. > > Now the chunksize computation is moved out of module to lv feature. And the > chunksize is picked as param in the module. > > The changes are committed: > https://github.com/gluster/gdeploy/commit/043d8448dc > > I tested with various values: > > 0. Specifying in the chunksize= variable within lv section. > 1. Specifying diskcount and stripesize > 2. Leaving to default (i.e not providing any in the config. > > [root@rhgs2 ~]# lvs -o chunk_size /dev/mapper/RHGS_vg1-lvthinpool > Chunk > 4.00m > [root@rhgs2 ~]# lvs -o chunk_size /dev/mapper/RHGS_vg1-lvthinpool > Chunk > 40.00m > [root@rhgs2 ~]# lvs -o chunk_size /dev/mapper/RHGS_vg1-lvthinpool > > Chunk > 64.00k > > Results look good, request more testing. Thanks Sac for the information. I have verified with other tests too ( with the scratch build 2.0.1-10 from Sac) and all looks good
Tested with gdeploy-2.0.1-11.el7rhgs and found that the chunksize is set properly. With the mention of diskcount as '10' and stripesize as '256', chunksize is set correctly as 2.50MB Marking the bug as VERIFIED
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://rhn.redhat.com/errata/RHEA-2017-0482.html