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 <jack@xxxxxxx> SUSE Labs, CR -- 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
