[Bugs] [Bug 1196026] quota: Used field shows data in "PB" after deleting data from volume(happens again)
bugzilla at redhat.com
bugzilla at redhat.com
Thu Aug 18 21:22:41 UTC 2016
https://bugzilla.redhat.com/show_bug.cgi?id=1196026
Dan <danodob at gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |danodob at gmail.com
--- Comment #5 from Dan <danodob at gmail.com> ---
Good day.
We are still seeing this same issue on 3.8.1 on multiple volumes. Is this a
confirmed fix? If so, what versions of gluster has it been added to?
When the quota value changes, there are no errors in the logs or any other
information that indicates there is an issue.
Environment:
2 primary gluster nodes on RHEL7.2
2 secondary gluster nodes on RHEL7.2 configured for geo-replication
One volume configuration:
Volume Name: appdata
Type: Replicate
Volume ID: 3bffc422-1bf3-4593-bf2e-399e0b3e2a7f
Status: Started
Number of Bricks: 1 x 2 = 2
Transport-type: tcp
Bricks:
Brick1: 192.168.66.102:/data/gluster/appdata/brick1
Brick2: 192.168.66.101:/data/gluster/appdata/brick1
Options Reconfigured:
changelog.changelog: on
geo-replication.ignore-pid-check: on
geo-replication.indexing: on
features.quota-deem-statfs: on
features.inode-quota: on
features.quota: on
transport.address-family: inet
performance.readdir-ahead: on
nfs.disable: on
cluster.enable-shared-storage: enable
# gluster volume status appdata
Status of volume: appdata
Gluster process TCP Port RDMA Port Online Pid
------------------------------------------------------------------------------
Brick 192.168.66.102:/data/gluster/
appdata/brick1 49192 0 Y 8502
Brick 192.168.66.101:/data/gluster/
appdata/brick1 49194 0 Y 6600
Self-heal Daemon on localhost N/A N/A Y 22714
Quota Daemon on localhost N/A N/A Y 18396
Self-heal Daemon on 10.0.0.102 N/A N/A Y 7343
Quota Daemon on 10.0.0.102 N/A N/A Y 26234
Quota status post issue:
Path Hard-limit Soft-limit Used
Available Soft-limit exceeded? Hard-limit exceeded?
-------------------------------------------------------------------------------------------------------------------------------
/ 6.0GB 80%(4.8GB) 16384.0PB
6.0GB No No
Could the 16384.0PB be the result of an evaluation expecting an unsigned
integer but receiving a -1?
We have just updated to 3.8.2 but have yet to work on replicating the issue.
Thank you in advance for your assistance.
Regards,
Dan
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=P71LhhmJ9u&a=cc_unsubscribe
More information about the Bugs
mailing list