Red Hat Bugzilla – Bug 1020253
quota: long time taken to update "EDQUOT"
Last modified: 2016-01-19 01:13:01 EST
Description of problem: set the limit to 1GB created a file 1GB now to create another file of 1GB, the "EDQUOT" is results after 3minutes 15sec whereas it should come immdiately Version-Release number of selected component (if applicable): glusterfs 3.4.0.35rhs How reproducible: seen this time Steps to Reproduce: 1. create a volume start it 2. enable quota, set limit of 1GB on "/" 3. create a file of 1GB [root@nfs3 ~]# gluster volume quota dist-rep1 list Path Hard-limit Soft-limit Used Available -------------------------------------------------------------------------------- / 1.0GB 80% 1.0GB 0Bytes 4. try creating another file of 1GB again Actual results: EDQUOT comes after 3min 15 sec [root@rhsauto030 nfs-test-dir]# time dd if=/dev/urandom of=1GBfile.1 bs=1G count=1 dd: writing `1GBfile.1': Disk quota exceeded 1+0 records in 0+0 records out 0 bytes (0 B) copied, 195.72 s, 0.0 kB/s real 3m15.860s user 0m0.001s sys 2m16.608s Expected results: if space is not there, then EDQUOT should come immediately. Additional info:
[shanks@localhost Music]$ time dd if=/dev/urandom of=1GBfile.2 bs=1G count=1 dd: writing `1GBfile.2': Disk quota exceeded dd: closing output file `1GBfile.2': Disk quota exceeded real 2m8.974s user 0m0.004s sys 2m8.892s [shanks@localhost Music]$ Version: glusterfs-server-3.4.0.40rhs-1.el6rhs.x86_64
dd on /dev/urandom is a slow process and it takes considerable time. Here is the output of the dd command on ext4 filesystem. [root@vm1 ~]# time dd if=/dev/urandom of=1GBfile.1 bs=1G count=1 1+0 records in 1+0 records out 1073741824 bytes (1.1 GB) copied, 155.771 s, 6.9 MB/s real 2m36.085s user 0m0.001s sys 1m42.553s Hence, closing this bug as it is expected behaviour.