Bug 1501349
| Summary: | CNS block device bigger than requested PVC size | ||
|---|---|---|---|
| Product: | [Red Hat Storage] Red Hat Gluster Storage | Reporter: | Elvir Kuric <ekuric> |
| Component: | kubernetes | Assignee: | Humble Chirammal <hchiramm> |
| Status: | CLOSED ERRATA | QA Contact: | krishnaram Karthick <kramdoss> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rhgs-3.0 | CC: | aos-bugs, aos-storage-staff, hchiramm, rhs-bugs |
| Target Milestone: | --- | ||
| Target Release: | CNS 3.9 | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-04-05 03:25:59 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1526414 | ||
|
Description
Elvir Kuric
2017-10-12 12:16:40 UTC
Elvir, this is actually working as expected. That said, if you want to have exactly "2GB" of space, you can create a PVC with "2GB" in its definition, this should create exactly "2GB" of storage. But if you request "2GiB", by PVC spec definition it create and round to next GB thats why you are getting "3GB" in mount point. Because GiB is 1024^3 where GB is 1000^3 , by PVC spec definition the claim should satisfy >= requested size and never less than the requested size. In short, this is not a bug rather working as expected. However please let me know if you have any question on this. (In reply to Humble Chirammal from comment #1) > Elvir, this is actually working as expected. That said, if you want to have > exactly "2GB" of space, you can create a PVC with "2GB" in its definition, > this should create exactly "2GB" of storage. But if you request "2GiB", by > PVC spec definition it create and round to next GB thats why you are getting > "3GB" in mount point. Because GiB is 1024^3 where GB is 1000^3 , by PVC spec > definition the claim should satisfy >= requested size and never less than > the requested size. > > In short, this is not a bug rather working as expected. However please let > me know if you have any question on this. This is only visible and case when cns block is used, cns file has sizes ok: PVC size == size of mount inside pod. (In reply to Elvir Kuric from comment #3) > (In reply to Humble Chirammal from comment #1) > > Elvir, this is actually working as expected. That said, if you want to have > > exactly "2GB" of space, you can create a PVC with "2GB" in its definition, > > this should create exactly "2GB" of storage. But if you request "2GiB", by > > PVC spec definition it create and round to next GB thats why you are getting > > "3GB" in mount point. Because GiB is 1024^3 where GB is 1000^3 , by PVC spec > > definition the claim should satisfy >= requested size and never less than > > the requested size. > > > > In short, this is not a bug rather working as expected. However please let > > me know if you have any question on this. > > This is only visible and case when cns block is used, cns file has sizes ok: > PVC size == size of mount inside pod. Agreed, but this has been corrected or adjusted for File volumes in upstream and it should be available from next OCP version onwards. The main inconsistency occured as Heketi only know about "GB" in its request. This is fixed in latest gluster-block provisioner container: rhgs-gluster-block-prov-container-3.3.1-1 and cns-deploy-6.0.0-2.el7rhgs verified in the following build - oc version oc v3.9.3 kubernetes v1.9.1+a0ce1bc657 features: Basic-Auth GSSAPI Kerberos SPNEGO Server https://dhcp47-22.lab.eng.blr.redhat.com:8443 openshift v3.9.3 kubernetes v1.9.1+a0ce1bc657 heketi version - heketi-6.0.0-6.el7rhgs.x86_64 [root@dhcp47-22 ~]# oc get pods NAME READY STATUS RESTARTS AGE glusterblock-storage-provisioner-dc-1-f2b5r 1/1 Running 0 3d glusterfs-storage-6d2rm 1/1 Running 0 3d glusterfs-storage-9whjp 1/1 Running 0 3d glusterfs-storage-pkw6f 1/1 Running 0 3d heketi-storage-1-q7fgw 1/1 Running 0 3d mongodb-01-1-qclfw 1/1 Running 0 21m mongodb-02-1-drh5l 1/1 Running 0 5m [root@dhcp47-22 ~]# oc get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE claim1 Bound pvc-f5b6de5b-22cb-11e8-853f-005056a5c33b 5Gi RWO gluster-block 3d mongodb-01 Bound pvc-6259dff2-25b0-11e8-a357-005056a5c33b 1Gi RWO gluster-block 21m mongodb-02 Bound pvc-7b8bf382-25b1-11e8-a357-005056a5c33b 2Gi RWO gluster-block 14m [root@dhcp47-22 ~]# oc rsh mongodb-01-1-qclfw sh-4.2# df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/docker-253:2-33576569-5a56029d00dc677d497bbfeb6ce8edd49cd04271ff7eb5aec930a443899e1642 10G 462M 9.6G 5% / tmpfs 24G 0 24G 0% /dev tmpfs 24G 0 24G 0% /sys/fs/cgroup /dev/mapper/vg_rhel_dhcp47----104--var-lv_var 59G 2.2G 57G 4% /etc/hosts shm 64M 0 64M 0% /dev/shm /dev/sdg 1014M 233M 782M 23% /var/lib/mongodb/data ----> 1GB device tmpfs 24G 16K 24G 1% /run/secrets/kubernetes.io/serviceaccount tmpfs 24G 0 24G 0% /proc/scsi tmpfs 24G 0 24G 0% /sys/firmware sh-4.2# exit [root@dhcp47-22 ~]# oc rsh mongodb-02-1-drh5l sh-4.2# df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/docker-253:2-33576537-e121a59b05a18d0bc1c8dc1f52470703330b142b91f3a757d5c337404fa761b0 10G 462M 9.6G 5% / tmpfs 24G 0 24G 0% /dev tmpfs 24G 0 24G 0% /sys/fs/cgroup /dev/mapper/vg_rhel_dhcp47----104--var-lv_var 59G 4.4G 55G 8% /etc/hosts shm 64M 0 64M 0% /dev/shm /dev/sdg 2.0G 233M 1.8G 12% /var/lib/mongodb/data -------> 2 GB device tmpfs 24G 16K 24G 1% /run/secrets/kubernetes.io/serviceaccount tmpfs 24G 0 24G 0% /proc/scsi tmpfs 24G 0 24G 0% /sys/firmware 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://access.redhat.com/errata/RHEA-2018:0642 |