Jan, this idea would work for us for now. As Andreas pointed out, we deal with MB-aligned quota limits, so this would give us the largest possible block quota limit value of 4 PB. However, I feel that it is worth to implement a clean 64-bit format, so that we avoid additional semantics (like quota unit size) and do make quota scale better (4 PB clusters already exist). Do you feel it might take considerably larger efforts to update quotatools to 64-bit version compared to 32-bit version with variable quota unit size? I'd like to start working on a kernel patch implementing 64-bit limits provided you approve the approach. Of course, it seems to be a good idea to have different file names for each version, not only for each format (where format and version have the same meaning as in quota kernel modules). The drawback is that then journalling quota users need to know the exact quota file version, not only format... Thank you for you kind response. Andrew. On Friday 07 March 2008 19:00:43 Jan Kara 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... > Honza -- 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
