Hide Forgot
over the fuse mount also the amount of data displayed is similar to the one by back-end [root@centos-qa-client-1 d1]# cd ../d2 [root@centos-qa-client-1 d2]# ls [root@centos-qa-client-1 d2]# dd if=/dev/zero of=f.1 bs=1KB count=512 512+0 records in 512+0 records out 512000 bytes (512 kB) copied, 0.570734 seconds, 897 kB/s [root@centos-qa-client-1 d2]# dd if=/dev/zero of=f.2 bs=1KB count=512 512+0 records in 512+0 records out 512000 bytes (512 kB) copied, 0.453694 seconds, 1.1 MB/s [root@centos-qa-client-1 d2]# dd if=/dev/zero of=f.3 bs=1KB count=8 dd: closing output file `f.3': Disk quota exceeded [root@centos-qa-client-1 d2]# ls -l total 1024 -rw-r--r-- 1 root root 512000 Apr 18 02:53 f.1 -rw-r--r-- 1 root root 512000 Apr 18 02:54 f.2 -rw-r--r-- 1 root root 1000 Apr 18 02:54 f.3 [root@centos-qa-client-1 d2]#
[root@centos-qa-client-3 sbin]# getfattr -m . -d -e hex /mnt/drep/d2/f.2 getfattr: Removing leading '/' from absolute path names # file: mnt/drep/d2/f.2 trusted.afr.drep-client-2=0x000000000000000000000000 trusted.afr.drep-client-3=0x000000000000000000000000 trusted.gfid=0x422837d4c6174f6880c050cd8650be21 trusted.glusterfs.quota.032245e2-9380-4deb-8dfa-ed1aebeb7ca4.contri=0x000000000007f000 after calculation 7f00=520192, where as the back-end shows 512000 [root@centos-qa-client-3 sbin]# ls -li /mnt/drep/d2/f.1 4620397 -rw-r--r-- 1 root root 512000 Apr 18 02:53 /mnt/drep/d2/f.1 hence the quota limits gets filled up soon. Finding this bug only in this glusterfs 3.2.0qa14 release.
This is due to the new way of using st_blocks to account for quota usage. Expected behaviour.