Description of problem: ----------------------- The precondition for the disk block size is that the disks used for volumes should be of same block size, for example, all 'vmstore' brick should be 512B, or all 'vmstore' bricks should be with block size 4KM and there is no mix that is allowed. The statement is true for LV cache as well.(ie.) SSD can be attached to thinpool composed of bricks of same disk block size. Which means SSD of 4KB block size, can't be attached to thinpool consists of 512B disk block sized disks. These checks should be done well before deployment and proper assertion, with proper error message should be thrown Version-Release number of selected component (if applicable): -------------------------------------------------------------- cockpit-ovirt-dashboard Actual results: --------------- No error thrown when mix of 4K and 512B disk block sized disks are used for one volume Expected results: ----------------- Preflight check added to validate that the gluster volumes do not contain disks of varied disk block sizes and throw proper error messages,in such situations
Here are few examples for valid and invalid scenarios Valid situations are: 1. 512B block sized disks used for engine volume 2. 4K block sized disks used for vmstore volume 3. 4K block sized SSD used as LV cache for thinpool composed of 4KB block sized disks 4. 512B block sized SSD used as LV cache for thinpool composed of 512B block sized disks Invalid scenarios: 1. 'vmstore' volume configuration has bricks created out of 4KB disk block sized disk on host1, host2 and host3 is using 512B brick for arbiter.etc
Tested with gluster-ansible-roles-1.0.5-22.el8rhgs When creating the volume with its brick on disks of varied block sizes, then error is thrown with proper information <snip> "item": { "pvname": "/dev/sdf", "vgname": "gluster_vg_sdf" }, "rc": 0, "start": "2020-11-07 01:58:33.888422", "stderr": "", "stderr_lines": [], "stdout": "4096", "stdout_lines": [ "4096" ] }, "msg": "The logical block size of disk is not 512 bytes" </snip> The check works only with CLI based automated deployment of RHHI-V There will be yet another bug to fix this in cockpit based deployment