From: Lars Braeuer (lbraeuer_at_mpex.net)
Date: Mon 07 Jul 2003 - 15:29:24 BST
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?
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?
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:
------------------------------------------------------
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.