[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F22424E.8070407@hitachi.com>
Date: Fri, 27 Jan 2012 15:21:02 +0900
From: HAYASAKA Mitsuo <mitsuo.hayasaka.hu@...achi.com>
To: Christoph Hellwig <hch@...radead.org>
Cc: Ben Myers <bpm@....com>, Alex Elder <aelder@....com>,
Christoph Hellwig <hch@....de>, xfs-masters@....sgi.com,
linux-kernel@...r.kernel.org, xfs@....sgi.com
Subject: Re: [PATCH 0/3] xfs: change available ranges in quota check
Hi Christoph,
(2012/01/25 2:46), Christoph Hellwig wrote:
> On Mon, Jan 23, 2012 at 12:45:14PM +0900, Mitsuo Hayasaka wrote:
>> Hi,
>>
>> This patch series changes available ranges of softlimit and
>> hardlimit in quota check, as follows.
>>
>> (1) Consider new reservation for quota check
>> The disk block reservation checks if (current usage + new
>> reservation) reach the quota limit although the inode reservation
>> does not use the new reservation for quota check. It should
>> consider it, as well. This is mandatory for (2).
>
> 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.
if (ninos > 0) { // ninos: # of new inodes expected to be allocated.
if (cur_usage >= limit)
goto error;
cur_usage += ninos;
}
It checks only current usage, but this code works well since the caller
always set the argument ninos to 1 or 0 in current xfs. So, inode can be
used up to the limits due to the one by one reservation.
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, this part is a kind of cleanup patch. I'm going to split the part
into another patch, and to send a new patch series.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists