Bug 1411259

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