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. > >
