On Monday 10 March 2008 18:20:59 Jan Kara wrote: > Wow. I wonder when 64-bits won't be enough :). Let's hope for the better :) > 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. Indeed, this would work. And it is a fast.. and an elegant solution. My point is that having 64-bit quota limit there's no need to implement new (and unusual) scaling interface for a user. Independent of filesystem size (whether it is 100 Gb or 100 Tb) user would be able to set quota limits as he used to, in kilobyte blocks. There would be no need for quota tools to obtainthe scaling factor before applying quota limits, no need to do the scaling "behind the curtains", in kernel. :) > 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. > As far as I know, we haven't yet hit this limit (though I can be wrong with this). But, yes, you are right, it is very likely to happen soon anyway. :) > > 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. > Too late. :) > 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... I was thinking that having separate file names could help, along with the magic field, to recognize the file format. As for conversion, I was thinking about such a sequence: create new file, write bad header, sync, convert, sync, write good header, sync, switch to the new file, finally erase the old one. With journalling, of course, adding rename seems to be atomic. Without journalling (ext2) could both files get lost in crash during conversion rename? Probably, it's not an issue here since those who take care of crashes use journalled filesystems. Then keeping the same name is ok... Thank you. Andrew. > > 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
