Re: [PATCH] quota: additional range checks and mem_dqblk updates?to handle 64-bit limits

[Andrew Perepechko <Andrew.Perepechko@Sun.COM>]

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