Bug 1300246
Summary: | [Tiering]: Values of watermarks, min free disk etc will be miscalculated with quota set on root directory of gluster volume | |||
---|---|---|---|---|
Product: | [Red Hat Storage] Red Hat Gluster Storage | Reporter: | krishnaram Karthick <kramdoss> | |
Component: | tier | Assignee: | Nithya Balachandran <nbalacha> | |
Status: | CLOSED ERRATA | QA Contact: | krishnaram Karthick <kramdoss> | |
Severity: | urgent | Docs Contact: | ||
Priority: | unspecified | |||
Version: | rhgs-3.1 | CC: | annair, asrivast, byarlaga, nbalacha, rhs-bugs, sankarshan, storage-qa-internal, vmallika | |
Target Milestone: | --- | Keywords: | ZStream | |
Target Release: | RHGS 3.1.2 | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | glusterfs-3.7.5-18 | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 1301473 (view as bug list) | Environment: | ||
Last Closed: | 2016-03-01 06:08:19 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: | 1296016, 1301473, 1302012 |
Description
krishnaram Karthick
2016-01-20 10:46:25 UTC
This is because 'features.quota-deem-statfs' is enabled by default and quota enforcer returns the 'limit value' on the directory and not the actual disk space. Could you please try with below workaround and see if it works? gluster volume set volname features.quota-deem-statfs off On a newly created volume with features.quota-deem-statfs set to 'off', quota limit set on root directory and attaching hot tier sets correct values of hot tier and watermarks work as expected. [see test-1] However, Turning 'features.quota-deem-statfs' 'on' and 'off' on the fly doesn't seem to fetch appropriate values of hot tier. Hot tier's value seems to be set to the initial value while tier is attached and doesn't change dynamically . This means we should turn off features.quota-deem-statfs even before hot tier is attached. Attaching hot tier and then turning off 'features.quota-deem-statfs' would again have incorrect value of hot tier. [see test-2] Test-1: 1) create a volume of size 2 TB 2) set quota on root directory to 1.5 TB 3) turn off 'features.quota-deem-statfs' 4) Write files on this volume - 40 x 2 GB files, 50 x 1GB files, 1000 x 100 MB files 5) Attach a hot tier of size 50 GB 6) set watermarks at 10% and 20%, i.e., 5GB and 10GB 7) Heat 20 files of size 2GB 8) Only 6 files (12 GB) were promoted and demotions started immediately, demoting 3 files. This leaves hot tier with 6 GB of data which is perfect. With features.quota-deem-statfs set to 'off' we seen the expected behavior. i.e., quota was set to 1.5 TB, hot tier's actual capacity was taken into account and watermarks were set accordingly. Files were promoted and demoted as expected. Test 2: Following test-1, test-2 was done. 1) Turn on 'features.quota-deem-statfs' [Now, hot tier's capacity should be incorrect value of 1.5 TB and watermarks should be at a very high value and only promotions would be seen] 2) Heat 10 x 2 GB files 3) No files were promoted even after continuous heating of files 4) stopped and started the volume under test 5) Heated 10 x 2 files, all 10 files were heated. i.e., new values of hot tier is in effect only after volume was restarted. Hence, the converse case would also be true. ie., having quota set to 1.5 TB and with hot tier attached, turning off 'features.quota-deem-statfs' would still fetch hot tier's value as 1.5 TB which is not expected. I'll update the bug if there are any more findings. Patch available at: https://code.engineering.redhat.com/gerrit/66435 Verified the fix in build glusterfs-server-3.7.5-18.el7rhgs.x86_64. Steps followed to verified, 1) On a gluster tier volume, enable quota and set root partition to 4 TB 2) Have deem.statfs enabled 3) promote files so as to cross high watermark --> files don't get promoted beyond high watermark 4) stop heating files. --> Demotion starts immediately Without the fix, high and low watermarks would have been 3.6 TB and 3 TB, no demotions would have happened and promotion would have happened way beyond value set in high watermark. 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/RHBA-2016-0193.html |