From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kara Subject: Re: [PATCH] quota: additional range checks and mem_dqblk updates to handle 64-bit limits Date: Mon, 10 Mar 2008 15:54:18 +0100 Message-ID: <20080310145418.GI24873@duck.suse.cz> References: <200803070329.29774.andrew.perepechko@sun.com> <20080307160043.GA16967@duck.suse.cz> <20080307211039.GC1881@webber.adilger.int> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andrew Perepechko , linux-fsdevel@vger.kernel.org, Johann Lombardi , Zhiyong Landen tian To: Andreas Dilger Return-path: Received: from styx.suse.cz ([82.119.242.94]:46417 "EHLO duck.suse.cz" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750923AbYCJOyT (ORCPT ); Mon, 10 Mar 2008 10:54:19 -0400 Content-Disposition: inline In-Reply-To: <20080307211039.GC1881@webber.adilger.int> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri 07-03-08 14:10:39, Andreas Dilger wrote: > On Mar 07, 2008 17:00 +0100, Jan Kara wrote: > > On Fri 07-03-08 03:29:29, Andrew Perepechko wrote: > > Great, thanks. The patch is fine. Yesterday evening I got an idea, how to > > solve your problem with too low limits even easier. What we could do is to > > introduce a "block-limit-scale" and "inode-limit-scale" parameter to the > > quota info and we keep the rest of the file format the same. Now, the meaning > > of this parameter would simply be a unit in which space and inode limits > > are specified. When you have a filesystem where you'd like to set quotas > > over 4 TB, you probably don't want to specify limits with 1KB precision > > anyway... So you can just set scale to 1MB or even 16MB (giving you maximal > > limit of 64 PB) and 10000 files or so. This has two advantages - only a few > > trivial modifications to current kernel code, no change in quota file space > > usage. We could then provide a way to set this scale via setquota / edquota > > (which would have to convert the whole file but that should be no big deal). > > What do you think about such solution? Would it fit your needs? Sorry, > > that I haven't through of this solution earlier... > > I can't speak fully for Andrew, as he is one of our quota gurus, but my > thought is that there is a risk of introducing corruption into the quota > file while it is entirely being rewritten and the system crashes or is > rebooted because the admin is impatient if this takes a long time. > > Moving to a second quota file is pretty safe, can be done incrementally > (i.e. check new file and then old file, if it exists) and allows a fallback > if the update fails in the middle. This rewriting is going to happen from tools in userspace - i.e., you turn quotas off, run a tool which does the conversion - it will create new converted file and just it move over the old file when it's done. So I think this should be no issue. > Also, while the "scale" parameter has merit in allowing the upper limit > of quota to be changed, the problem still exists on how to measure the > actual quota usage in that case. If we assume a scale of 1MB (which is > fine for Lustre, that is the minimum we grant quota to different servers > anyways :-) but some user is only consuming 100k of quota at a time, then > this will continually be rounded down to 0 quota usage... Quota usage is already measured in bytes and the format has 64-bit field for it already. So that's no problem. But I've just realized we might have a problem in case we want to allow user to have more that 2^32 files as the number of files user has is stored in a 32-bit field. Honza -- Jan Kara SUSE Labs, CR