From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Wed 30 Oct 2002 - 20:12:36 GMT
On Wed, Oct 30, 2002 at 08:16:05PM -0500, Dave wrote:
> On Wed, 2002-10-30 at 07:58, Herbert Poetzl wrote:
>
> > A) user/group quota within a context
> > should ...
> >
> > - be working like on any other machine ..
> > - need no modifications to userland tools at all
> > - be only valid and accounting for the context
> >
> > B) physical server per context user/group quota
> > should ...
> >
> > - work like usual, but give information about the context
> > - be able to set specific context/user context/group quota
> > - will require changes in userland tools ...
> >
> > C) context quota (total sum of users per context)
> > should ...
> >
> > - work like user or group quota, but based on the context
> > - need no changes for quota tools, if they are general
> > enough to handle all kernel quotas (not only user/group)
>
> This is a good summary of what could be a definitive solution. Off
> course it will take some persuasion to merge your patches in the main
> quotatools tree.
I already contacted the quota-tools author(s) and
to my suprise I got the following answer:
] ...
] I agree that in quota tools there are places which allow
] only USER/GROUP quotas but I think it shouldn't be too
] hard to fix that (I can have a look at it). ...
] Jan Kara (Honza)
so I am confident, that this issue will resolve
automagically ...
> In the mean time, as long as A works, there could be little need for the
> physical server to set context/user and context/group quota (you can
> always do this as A after switching to the right context). Regarding C,
> this can be dealt with either as we're currently doing with the LVM hack
> or by hacking the kernel some more as was previously posted.
and fortunately, verson A should already be working, because
the remapping I do within the context, assigns an unique
ID to every user of each context ...
(point B and C too, but unfortunately I had no time/machine
to test the code or functionality, but we'll see ... )
> > I never, ever tried to make the quota-tools within a context
> > aware of the context ...
>
> This is my fault for not reading your code. Sorry.
>
> > the special user aproach (for context quota information) seems
> > tempting, but in my opinion there are several drawbacks ...
>
> I agree on the concept. A third type of quota seems more natural to me
> now, however...
however what? provide some reasons why this should be bad,
or any other attempt should be better ...
As I said, I am always open to suggestions ...
> > - how to handle context quota violations within the kernel
> > for users which do not exceed their personal quota?
> > Simply report you exceeded your quota, and on check report
> > that still space/quota is left?
>
> IMHO, It should not be possible for a context to exceed it's quota when
> some users have not. This is the point of quota mechanism. Guarantee
> space on the disk and not allow for over-booking.
see, and exactly this is naturally and automatically done,
if the third quota is intact (active), but you have to handle
special cases and explanations (for the user) if some kind
of magic user quota (which accounts for the context) is
exceeded. that is one of my reasons to add the third quota type.
> Allocated user quota
> should be subtracted from the total context quota, so that any users
> with no quota should not be able to use that space. So in a way, users
> with quota will have their space, while other users will share what is
> left. It is the only way to guarantee file allocation.
>
> So, if context has 1Gig, and we allocate 300megs to users, all the other
> users will get at max 700megs.
best,
Herbert