Jan Kara wrote:
On Sat 08-03-08 03:56:17, Andrew Perepechko wrote:
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).
Wow. I wonder when 64-bits won't be enough :). Anyway, my point was that
when you get to 4 PB limits, you can just run: "setquota --set-scale 1GB"
(hopefully at that time you won't care about rounding limits to 1GB) and
you are at 4 HB limits (or what is the right suffix). No quota format
change needed.
But what I fear more is that we may run out of 2^32 limit on the number
of files one user can have (I don't have experience with that large systems
but I guess you are comming near to 2^32 files on the filesystem, aren't
you?). And for that we would have to do basically the changes you've
suggested
The core of the "scale" way is: it does harm to the accuracy of quota so
that we can set a larger
quota limitation. If the scale is 1G, 500M quota the user sets is equal
to 0. Some customers may
like it; others may confuse. Anyway, we can't regulate the way of users
using quota.
For lustre, I have a plan to set a minimum unit to 1K instead of current
1M. So 64bit quota is
a must. I just wonder why not we implement these two points in different
patches:
1. 64bit quota limitation
2. give a "scale" to the users who are glad to adjust it.
--
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
