Bug 801387 - quota: crossing directory limits
quota: crossing directory limits
Status: CLOSED DEFERRED
Product: GlusterFS
Classification: Community
Component: quota (Show other bugs)
pre-release
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Raghavendra G
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-08 07:20 EST by Saurabh
Modified: 2016-01-19 01:09 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-03-16 00:09:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Saurabh 2012-03-08 07:20:52 EST
Description of problem:
directory limits are getting crossed and hence the volume level as well,




Version-Release number of selected component (if applicable):
3.3.0qa26

How reproducible:
always

Steps to Reproduce:
1. create a distribute-replicate volume
2. put volume and directory level limits
3. create data inside the directories
  
Actual results:
the directory limits are getting crossed


Expected results:
the limits should be respected


Additional info:


[root@RHEL6 ~]# gluster volume quota quota_dist_rep list
	path		  limit_set	     size
----------------------------------------------------------------------------------
/                           2MB                3.2MB
/d0                       200KB                1.6MB
/d1                       200KB                1.6MB
[root@RHEL6 ~]# 


extended attribute information,


[root@RHSSA1 ~]# getfattr -m . -d -e hex /export-xfs/quota_dist_rep.1331200944
getfattr: Removing leading '/' from absolute path names
# file: export-xfs/quota_dist_rep.1331200944
security.selinux=0x756e636f6e66696e65645f753a6f626a6563745f723a66696c655f743a733000
trusted.gfid=0x00000000000000000000000000000001
trusted.glusterfs.dht=0x0000000100000000000000007ffffffe
trusted.glusterfs.quota.dirty=0x3000
trusted.glusterfs.quota.size=0x00000000001dc000
trusted.glusterfs.volume-id=0x95253ee63b924adf9f0ec9cf0b9b7b5e

[root@RHSSA1 ~]# getfattr -m . -d -e hex /export-xfs/quota_dist_rep.1331200944/d0
getfattr: Removing leading '/' from absolute path names
# file: export-xfs/quota_dist_rep.1331200944/d0
security.selinux=0x756e636f6e66696e65645f753a6f626a6563745f723a66696c655f743a733000
trusted.gfid=0xb3f6a3f3e1384fff8cdb8373edbe9405
trusted.glusterfs.dht=0x0000000100000000000000007ffffffe
trusted.glusterfs.quota.00000000-0000-0000-0000-000000000001.contri=0x00000000000ee000
trusted.glusterfs.quota.dirty=0x3000
trusted.glusterfs.quota.size=0x00000000000ee000

[root@RHSSA1 ~]# 
[root@RHSSA1 ~]# 
[root@RHSSA1 ~]# 
[root@RHSSA1 ~]# getfattr -m . -d -e hex /export-xfs/quota_dist_rep.1331200944/d1
getfattr: Removing leading '/' from absolute path names
# file: export-xfs/quota_dist_rep.1331200944/d1
security.selinux=0x756e636f6e66696e65645f753a6f626a6563745f723a66696c655f743a733000
trusted.gfid=0x0206ff9dae4a4f148977c8db8feff66b
trusted.glusterfs.dht=0x0000000100000000000000007ffffffe
trusted.glusterfs.quota.00000000-0000-0000-0000-000000000001.contri=0x00000000000ee000
trusted.glusterfs.quota.dirty=0x3000
trusted.glusterfs.quota.size=0x00000000000ee000

[root@RHSSA1 ~]# 
[root@RHSSA1 ~]# getfattr -m . -d -e hex /export-xfs/quota_dist_rep.133120097
getfattr: /export-xfs/quota_dist_rep.133120097: No such file or directory
[root@RHSSA1 ~]# getfattr -m . -d -e hex /export-xfs/quota_dist_rep.1331200947
getfattr: Removing leading '/' from absolute path names
# file: export-xfs/quota_dist_rep.1331200947
security.selinux=0x756e636f6e66696e65645f753a6f626a6563745f723a66696c655f743a733000
trusted.gfid=0x00000000000000000000000000000001
trusted.glusterfs.dht=0x00000001000000007fffffffffffffff
trusted.glusterfs.quota.dirty=0x3000
trusted.glusterfs.quota.size=0x0000000000154000
trusted.glusterfs.volume-id=0x95253ee63b924adf9f0ec9cf0b9b7b5e

[root@RHSSA1 ~]# ^M
: command not found
[root@RHSSA1 ~]# getfattr -m . -d -e hex /export-xfs/quota_dist_rep.1331200947/d0
getfattr: Removing leading '/' from absolute path names
# file: export-xfs/quota_dist_rep.1331200947/d0
security.selinux=0x756e636f6e66696e65645f753a6f626a6563745f723a66696c655f743a733000
trusted.gfid=0xb3f6a3f3e1384fff8cdb8373edbe9405
trusted.glusterfs.dht=0x00000001000000007fffffffffffffff
trusted.glusterfs.quota.00000000-0000-0000-0000-000000000001.contri=0x00000000000aa000
trusted.glusterfs.quota.dirty=0x3000
trusted.glusterfs.quota.size=0x00000000000aa000

[root@RHSSA1 ~]# getfattr -m . -d -e hex /export-xfs/quota_dist_rep.1331200947/d1
getfattr: Removing leading '/' from absolute path names
# file: export-xfs/quota_dist_rep.1331200947/d1
security.selinux=0x756e636f6e66696e65645f753a6f626a6563745f723a66696c655f743a733000
trusted.gfid=0x0206ff9dae4a4f148977c8db8feff66b
trusted.glusterfs.dht=0x00000001000000007fffffffffffffff
trusted.glusterfs.quota.00000000-0000-0000-0000-000000000001.contri=0x00000000000aa000
trusted.glusterfs.quota.dirty=0x3000
trusted.glusterfs.quota.size=0x00000000000aa000

[root@RHSSA1 ~]#
Comment 1 Saurabh 2012-03-08 08:08:52 EST
same is the case for nested directories
Comment 2 Raghavendra G 2012-03-13 08:56:05 EDT
Saurabh,

Can you run the tests with "performance.write-behind off" on client and with io-threads commented out on server side? I ran the tests with these two translators off and observed no overshooting of quota. If this is the same case with your setup, mark this as a known issue which is happening because of quota updation delay on bricks. Updation is a background process, with write-behind and io-threads, there can be many writes that happen in parallel within the updation window. The size by which quota is overshoot should be equal to the size of writes that happen in the updation window.

regards,
Raghavendra.
Comment 3 Saurabh 2012-03-14 07:43:12 EDT
Raghavendra,

   I disables write-behind and io-threads and the directory limits were not crossed.

  Infact the "mv" of files from one directory to another one happened within the limits set earlier.

  so, according to me this should either be documented or fixed as without setting write-behind and io-threads the limits are crossed by a large number.

Note You need to log in before you can comment on or make changes to this bug.