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.
