About this list Date view Thread view Subject view Author view Attachment view

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

Disk quotas for user quota_user (uid 1000): none

I think I'm going crazy. ;) j/k

thanks for your help herbert!


> everything, except for the mount, should be done from
> 'inside' the virtual server ...
>>my hostsystem setup:
>>vquota patch
> 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.

About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Mon 07 Jul 2003 - 15:50:39 BST by hypermail 2.1.3