From: HAYASAKA Mitsuo <mitsuo.hayasaka.hu@hitachi.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com,
xfs-masters@oss.sgi.com, Ben Myers <bpm@sgi.com>,
Alex Elder <aelder@sgi.com>, Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH 0/3] xfs: change available ranges in quota check
Date: Fri, 27 Jan 2012 23:02:11 +0900 [thread overview]
Message-ID: <4F22AE63.2020809@hitachi.com> (raw)
In-Reply-To: <20120127110238.GB31093@infradead.org>
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.
Regards.
(2012/01/27 20:02), Christoph Hellwig wrote:
> On Fri, Jan 27, 2012 at 03:21:02PM +0900, HAYASAKA Mitsuo wrote:
>>> Can you send a testcase that reproduces issues with the old behaviour?
>>>
>>
>> Regarding (1) related to inode reservation, current xfs works well
>> because inode is reserved one by one if required.
>>
>> For example, when an new inode tries to be reserved in xfs_trans_dqresv(),
>> it checks quota as follows.
>
> I'm just curious what the intent behdind the patches was. They look
> good to me, but I wonder why we need to change it at all.
>
>> To make it more general, this check should be the same way as the new
>> block quota check introduced in the PATCH 2/3 where the disk block can
>> be used up to the block quota limits.
>
> So I guess that's the part we'd want a test case for if possible.
>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
WARNING: multiple messages have this Message-ID (diff)
From: HAYASAKA Mitsuo <mitsuo.hayasaka.hu@hitachi.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com,
xfs-masters@oss.sgi.com, Ben Myers <bpm@sgi.com>,
Alex Elder <aelder@sgi.com>, Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH 0/3] xfs: change available ranges in quota check
Date: Fri, 27 Jan 2012 23:02:11 +0900 [thread overview]
Message-ID: <4F22AE63.2020809@hitachi.com> (raw)
In-Reply-To: <20120127110238.GB31093@infradead.org>
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.
Regards.
(2012/01/27 20:02), Christoph Hellwig wrote:
> On Fri, Jan 27, 2012 at 03:21:02PM +0900, HAYASAKA Mitsuo wrote:
>>> Can you send a testcase that reproduces issues with the old behaviour?
>>>
>>
>> Regarding (1) related to inode reservation, current xfs works well
>> because inode is reserved one by one if required.
>>
>> For example, when an new inode tries to be reserved in xfs_trans_dqresv(),
>> it checks quota as follows.
>
> I'm just curious what the intent behdind the patches was. They look
> good to me, but I wonder why we need to change it at all.
>
>> To make it more general, this check should be the same way as the new
>> block quota check introduced in the PATCH 2/3 where the disk block can
>> be used up to the block quota limits.
>
> So I guess that's the part we'd want a test case for if possible.
>
next prev parent reply other threads:[~2012-01-27 14:02 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-23 3:45 [PATCH 0/3] xfs: change available ranges in quota check Mitsuo Hayasaka
2012-01-23 3:45 ` Mitsuo Hayasaka
2012-01-23 3:45 ` [PATCH 1/3] xfs: consider new reservation for quota check on inode reservation Mitsuo Hayasaka
2012-01-23 3:45 ` Mitsuo Hayasaka
2012-01-23 3:45 ` [PATCH 2/3] xfs: change available ranges of softlimit and hardlimit in quota check Mitsuo Hayasaka
2012-01-23 3:45 ` Mitsuo Hayasaka
2012-01-23 3:45 ` [PATCH 3/3] xfs: cleanup quota check on disk blocks and inodes reservations Mitsuo Hayasaka
2012-01-23 3:45 ` Mitsuo Hayasaka
2012-02-02 16:07 ` Christoph Hellwig
2012-02-02 16:07 ` Christoph Hellwig
2012-02-03 4:05 ` HAYASAKA Mitsuo
2012-02-03 4:05 ` HAYASAKA Mitsuo
2012-01-24 17:46 ` [PATCH 0/3] xfs: change available ranges in quota check Christoph Hellwig
2012-01-24 17:46 ` Christoph Hellwig
2012-01-27 6:21 ` HAYASAKA Mitsuo
2012-01-27 6:21 ` HAYASAKA Mitsuo
2012-01-27 11:02 ` Christoph Hellwig
2012-01-27 11:02 ` Christoph Hellwig
2012-01-27 14:02 ` HAYASAKA Mitsuo [this message]
2012-01-27 14:02 ` HAYASAKA Mitsuo
2012-01-27 14:04 ` Christoph Hellwig
2012-01-27 14:04 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F22AE63.2020809@hitachi.com \
--to=mitsuo.hayasaka.hu@hitachi.com \
--cc=aelder@sgi.com \
--cc=bpm@sgi.com \
--cc=hch@infradead.org \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=xfs-masters@oss.sgi.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.