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. 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... Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
