Re: [PATCH 0/3] xfs: change available ranges in quota check

[Christoph Hellwig]

On Fri, Jan 27, 2012 at 11:02:11PM +0900, HAYASAKA Mitsuo wrote:
> Hi Christoph,
> 
> I'd like to explain the reason why I sent the patch series.
> 
> Here is an example where I activated user quota and set each softlimit and
> hardlimit as follows.
> 
>        | softlimit | hardlimit 
> -------------------------------
>  block |    1M     |    2M
> -------------------------------
>  inode |     3     |     5
> 
> I succeeded to create files up to the inode hardlimit using touch command.
> The quota information is shown as follows.
> 
> # xfs_quota -x -c 'report -u -b -i -h' /mnt/xfs2
> User quota on /mnt/xfs2 (/dev/vdb)
>                         Blocks                            Inodes              
> User ID      Used   Soft   Hard Warn/Grace     Used   Soft   Hard Warn/Grace  
> ---------- --------------------------------- --------------------------------- 
> root            0      0      0  00 [------]      3      0      0  00 [------]
> xfstest01       0     1M     2M  00 [------]      5      3      5  00 [6 days]
> 						 ~~~~	        ~~
> 
> However, I failed to create and add another file due to the quota limitation.
> 
> $ touch /mnt/xfs2/dir00/file05
> touch: cannot touch `/mnt/xfs2/dir00/file05': Disk quota exceeded
> 
> It seems the inode quota works well.
> 
> Regarding the block quota, I got the quota limitation message even if I
> created a 2MB file which is equal to the hardlimit of disk quota.
> 
> $ dd if=/dev/zero of=/mnt/xfs2/dir00/file01 bs=2M count=1
> dd: writing `/mnt/xfs2/dir00/file01': Disk quota exceeded
> 1+0 records in			     ~~~~~~~~~~~~~~~~~~~~~
> 0+0 records out
> 2093056 bytes (2.1 MB) copied, 0.00561516 s, 373 MB/s
> 
> I'd like to change the available range of the block quota, and
> also change the inode quota check to the same way as the block check
> introduced in PATCH 2/3 to make it more general.

Makes sense.  Can you create an xfstests testcase containing the above
test case?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/