From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Mon 07 Jul 2003 - 16:45:53 BST
Hi Lars!
On Mon, Jul 07, 2003 at 04:29:24PM +0200, Lars Braeuer wrote:
> ok, it seems to work now. after working on the same user the
> whole time, I added a new one while quota was turned on.
> all the stats (blocks, inodes) seem to be update fine now
> and even the user can view his quotas with "quota". I think
> I'm going to reinstall my test vserver and see if it works
> from the start now.
>
> also any new usernames are reported as id with a leading "#"
> by repquota but not as the acutal username. I hope this is
> the right behaviour?
a simple explanation should clarify that:
(see http://www.13thfloor.at/VServer/Concepts.shtml)
quota tools try to resolve (hide) the numeric values
the quota system actually uses (can be supressed with
the -n option) but as the context specific versions
of for example 'root' will have some offset (2^16 * ctx)
they won't be found in the host (physical) server.
although they should be shown correctly in the virtual
server, otherwise something _is_ wrong ...
> I didn't lock the vserver to a single security context before
> (using S_CONTEXT). maybe you should mention this in your
> how-to for other people reading it?
you are absolutely right, I will add this to the how-to ...
> after locking the vserver to a context id quotas were properly
> saved even after restarting the vserver.
>
> so you can ignore *most* of my last mail:
let me know if something is unclear
best,
Herbert
> ------------------------------------------------------
>
>
> Herbert Poetzl wrote:
> >
> >the current linux quota solution (not only vquota ;)
> >is a hybrid kernel/user space solution, where information
> >is passed over different channels ...
> >
> > - filesystem (the quota files)
> > - quotactl on the device
> >
> >if you have quota turned off, for example, information
> >can only be exchanged over the filesystem, which, if no
> >sync is done later on, can result in a copletely different
> >view, from the kernel side ...
>
> how could such a sync be done? with quotacheck (-f) or another tool?
>
> >
> >the hopefully correct sequence should be:
> >
> > - mount filesystem with quota options
> > - perform quotacheck (probably forced to overwrite)
> > - turn on quota (from now on kernel should be in sync with files)
> > - edit quota values for any user
> > - check with repquota
> > - check with dd (hard way *G*)
>
> ah ok I see, so not the actual username is used, but an ID that is probably
> derived from that 32bit calculation?
>
> repquota (abstract)
> -------------------------
> quota_user +- 41 10 500 5days 10 0 0
> #132072 -- 0 100 500 0 0 0
> -------------------------
>
> as you can see, the first line is the actual user I edited yesterday before
> turning the quota on. the next line seems to be the userid vquota calculated
> (you probably know exactly why it's there ;). after turning quota on I
> edited
> the quota of the user "quota_user" and the values showed up right next to
> "#132072". but the block and inode stats are not updated correctly (yes
> quotacheck ran before turning the quota on). since running quotacheck after
> the
> quota has been turned on is not a good idea, is there another way of
> updating
> these stats (blocks/inodes)?
>
> su'ing to user "quota_user" and entering "quota" to see the quota for this
> user
> outputs:
>
> Disk quotas for user quota_user (uid 1000): none
>
> I think I'm going crazy. ;) j/k
>
> thanks for your help herbert!
>
> Lars
>
>
> >
> >everything, except for the mount, should be done from
> >'inside' the virtual server ...
> >
> >
> >>my hostsystem setup:
> >>linux-2.4.20-ctx17
> >>vquota patch
> >>quota-tools-3.08
> >>vquota-tools-0.12
> >
> >
> >hmm, why not 2.4.21? are there any reasons?
>
> well, you probably remember my problems with the 2.4.21 a few days ago.
> saving
> quota's for users in the hostsystem didn't even work with 2.4.21. there's
> also a
> weird udp bug that's related to the ctx patch. I can't fix this for the
> moment
> and I wouldn't even know where to start.
> once everything's working with 2.4.20 I will start trying to figure out
> what's
> wrong with the 2.4.21 on my system.
>
>