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. > 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? Well, I don't fear that much about quota tools but more about the kernel code and duplication of code in there. > I'd like to start working on a kernel patch implementing 64-bit limits provided > you approve the approach. I'm glad you're eager to work on that :) I'd just like to think twice before going for the new format and changing quota code. > 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... Hmm, I don't get this. I don't think there's a real need for changing the quota file name. That is exactly what I'd like to avoid. Why do you think new quota file name is better? Those conversion things Andreas pointed out, are solved by doing the conversion into the temporary file... 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
