Description of problem: When swithcing to 4k support, we missed couple of place where there is still hardcoded 512B block size. All these pieces of code has to be fixed or rewritten. directio module: * DirectFile.read() * DirectFile.write() misc module: * readblock() * _alignData()
The included patch is needed for file based storage which should be supported in 4.3.7, but the other cases mentioned here are all used only in block storage, which will not be supported in 4.3.7. Lets handle only file based storage in this bug, and file another bug for 4k support in block storage, targeted to 4.4.
RFE for 4k support in block SD: https://bugzilla.redhat.com/1753263
Please provide a clear scenario of how to verify this bug.
There isn't any particular test how to verify it, the verification from QA point of view IMHO should be that there isn't any regression in vdsm.
I will QA_ACKED this once also Sas give his OK to test it at RHHI ENV as well to see basic functionality. Just to be clear we only have the hardware to test gluster 4K. As this bug is about file storage gluster is the only file storage that will be tested. As I stated before: verification will take time as we need to make sure that: 1) We will run TierX regressions(with regular non-4K storages) anyway when this fix will be introduced for downstream and see no issues are seen. 2) RHHI team will consume this fix and see if it affects RHHI operations(which are made on 4K enabled storage).
(In reply to Avihai from comment #10) > I will QA_ACKED this once also Sas give his OK to test it at RHHI ENV as > well to see basic functionality. > > Just to be clear we only have the hardware to test gluster 4K. > As this bug is about file storage gluster is the only file storage that will > be tested. > > As I stated before: > verification will take time as we need to make sure that: > > 1) We will run TierX regressions(with regular non-4K storages) anyway when > this fix will be introduced for downstream and see no issues are seen. > 2) RHHI team will consume this fix and see if it affects RHHI > operations(which are made on 4K enabled storage). Hi Sas, Please ack that this part(2) will be handled by your team so we can QA_ACK this bug.
4KN support with RHHI-V takes more time, as all the regression test cases needs to be run with 4KN setup. It was decided in the RHHI-V pgm to target 4KN support with RHHI-V with RHV 4.3.8. Hence negating the ack for qualification of this bug for RHV 4,3,7
this bug has been cloned for 4.3.8 inclusion, resetting this one to 4.4.0 regression testing. Asking again for QA ack
(In reply to Sandro Bonazzola from comment #13) > this bug has been cloned for 4.3.8 inclusion, resetting this one to 4.4.0 > regression testing. > Asking again for QA ack Thanks Sandro. This bug is blocked on the RHHI deployment - https://bugzilla.redhat.com/show_bug.cgi?id=1823423 - and once that issue is fixed, I could help to verify this bug
Tested with RHVH 4.4.1 with vdsm-4.40.22-1 Ran all the RHHI test cases on 4K glusterfs storage domain from RHHI-V perspective. No issues seen
This bugzilla is included in oVirt 4.4.0 release, published on May 20th 2020. Since the problem described in this bug report should be resolved in oVirt 4.4.0 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.