Koozali.org: home of the SME Server

quotas

Tom Haynes

quotas
« on: August 21, 2003, 07:30:28 PM »
Greetings...

I have a new installation with about 750 users. This is a file server for students, and I imported the user files from a Novell restore and chown'd the files user:user. The permissions and access rights seem correct.

I run the LAT quota script to set quotas for all of the users. It takes about 4.5 hours. When I check quotas in server-manager, the soft/hard limits are correct, but the usage is not. It will show that a student has 0 in the current usage column. The test accounts created that didn't have files imported by a script don't exhibit this. A mapped student account will not show the limit and the quotas do not seem to be working.

Sometimes at the end of the day, the hard/soft limits are both zero even though nothing has been changed. The only cron job running in the late afternoon rsyncs the homes to a remote machine in case something has to be administratively restored after the "machine eats HW" during study hours.

Is there something I need to do to get the quotas to "see" the files? Accounts for teachers had no files imported, and they seem to be taking the quotas just fine. Oddly a few student accounts are registering because I got a single "over quota" account this AM when really there are about 20 accounts that are over.

The machine is a dual P3 900 with a SCSI HD and a gig of ram. It is running 5.6U4. The HD is a 32 gig, and the quotas are going to be critical to making this work this year.

Regards...   Tom

Michiel Blotwijk

Re: quotas
« Reply #1 on: August 22, 2003, 12:40:48 AM »
Try

repquota /dev/hda3 | less

and check the "funny" users. What does it say there under "used" ?

Michiel

Tom Haynes

Re: quotas
« Reply #2 on: August 22, 2003, 01:27:03 AM »
Hmmm...

Now I am really puzzled.

Here is the only output.

repquota: Can't resolve mountpoint for device PWD=/root
repquota: Can't initialize mountpoint scan.

Tom Haynes

Re: quotas
« Reply #3 on: August 22, 2003, 01:44:31 AM »
Ok, I am a little slow...

I have tried this again with sda3 instead of hda3.

This time I got

[root@student root]# repquota /dev/sda3 | less
...skipping...
~
~
~
~
~

Tom Haynes

Re: quotas
« Reply #4 on: August 22, 2003, 01:52:02 AM »
If I run repquota -a, I get the following for the first few staff accounts created via the server-manager.

alexanm   --     100   25600   30720             26     0     0
turnbul   --     100   25600   30720             26     0     0
littles   --     100   25600   30720             26     0     0
choward   --     100   25600   30720             26     0     0
Segmentation fault

Michiel Blotwijk

Re: quotas
« Reply #5 on: August 22, 2003, 03:34:32 AM »
> Segmentation fault

Segmentation fault? That starts to look like a bug in SME. Only yesterday there was a similar issue with adding a large number of users resulting in a SegFault (http://forums.contribs.org/index.php?topic=18225.msg71482#msg71482).

Just send a message to smebugs@mitel.com to start the thing going.

Meanwhile you could try the following things:
- quotacheck -vamfvug (make sure no files are open!)
- turn quota off for some of the funny users and turn them back on via the server manager.
- turn quota off for all users (lat-quota -c="* | 0 | 0" ) and do again a quotacheck -vamfvug.

Michiel

Michiel Blotwijk

Re: quotas
« Reply #6 on: August 22, 2003, 03:51:47 AM »

Greg Zartman

Re: quotas
« Reply #7 on: August 22, 2003, 03:52:59 AM »
> Segmentation fault? That starts to look like a bug in SME.
> Only yesterday there was a similar issue with adding a large
> number of users resulting in a SegFault
> (http://forums.contribs.org/index.php?topic=18225.msg71482#msg71482).

Simular issues??  The disussion that you quote was the result of Abe hitting the ceiling of the Redhat account utilities.  The only simularity I can see between these two issues is the resulting error message --- and that's not much.  A segfault is about like getting a "syntax error" when coding.  Very general message.

I ran into an issue with quotas some time back.  I believe with SME 5.0.   I seem to recall that turning quotas off and then back on again cleared it up.  

Either way, a message to smebugs couldn't hurt.

Greg Zartman

Michiel Blotwijk

Re: quotas
« Reply #8 on: August 22, 2003, 04:12:48 AM »
> The only simularity I can see between these two issues is the resulting error message

Large number of users leading to a segmentation fault. That seems to me more like a bug than a configuration problem. That's all.

Tom Haynes

Re: quotas
« Reply #9 on: August 24, 2003, 06:35:08 PM »
I submitted a bug, and heard back that it may be linked to a quotas kernel bug.

They recommended that I upgrade to 6.0b3.

Fearing what would break (userpanel, etc.), I installed on a test box. I restored the base OS first and then transferred over the /etc/group, /etc/password, /etc/shadow, and /etc/samba

I checked and all my users seemed to be there and the test accounts map, etc. I then restored the /home directory and checked the quotas in server-manager from time to time to watch progress. I was encouraged by the fact that the account totals seemed to be corrrect.

After about 500 users, some of the early accounts started showing 0 for the files owned by the user.

I then did an upgrade to 6.0b3. The upgrade went smoothly, and my userpanel was broken, but other things seemed to be working correctly. I didn't do much testing here, but just a quick glance...

The quotas still show totals for a few users, and nothing for the majority.

"repquota -a" seg faults immediately and no longer gives a partial report of early accounts created.

Tom Haynes

Re: quotas
« Reply #10 on: August 26, 2003, 05:00:38 AM »
Quotas are now qorking on the 5.6U4 and the 6.0b3 boxes.

It took running "quotacheck -acfm" from either the 6.0b3 or 5.6U4 command line generates a new aquota.user file, and it is about 4 times the size. The quotas then work as expected on either machine.

I added a cron job to regenerate the quota files every night to try to keep things from getting corrupted again.