From owner-freebsd-hackers Fri Apr 13 13: 4:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from relayout1.micronpc.com (meihost.micronpc.com [209.19.139.2]) by hub.freebsd.org (Postfix) with ESMTP id 0C49437B507 for ; Fri, 13 Apr 2001 13:04:14 -0700 (PDT) (envelope-from mpsimerson@hostpro.com) Received: from mei00wssout01.micron.com (mei00wssout01.micronpc.com [172.30.41.216]) by relayout1.micronpc.com (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP id OAA06074; Fri, 13 Apr 2001 14:03:47 -0600 Received: from 172.30.41.146 by mei00wssout01.micron.com with ESMTP ( Tumbleweed MMS SMTP Relay(WSS) v4.5); Fri, 13 Apr 2001 14:03:47 -0600 X-Server-Uuid: 6b1d535a-5b27-11d3-bf09-00902786a6a3 Received: by imcout1.micronpc.com with Internet Mail Service ( 5.5.2650.21) id <26J7QK5G>; Fri, 13 Apr 2001 14:04:28 -0600 Message-ID: <8D18712B2604D411A6BB009027F6449801B4B5B9@0SEA01EXSRV1> From: "Matt Simerson" To: "'Ken Stox'" Cc: "'freebsd-hackers@freebsd.org'" Subject: RE: Quota reporting is inaccurate. Date: Fri, 13 Apr 2001 14:03:34 -0600 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 X-WSS-ID: 16C9842954480-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Actually, I believe it reports based upon the contents of the BLOCKSIZE environment variable which is 1k or 1024 bytes for the purposes of this discussion. In either case, you'll notice that the reporting shown below accurately shows that the users quota is very near the limit and the quota is set at 350MB. Interestingly enough, I added check_quotas="YES" to /etc/rc.conf and rebooted. That fixed that users quota problem. I'm not sure if it was the rebooting (and clearing the kernels idea of what the quota should be) or if running quotacheck in single user mode did it. I have to guess the former because quotacheck's results should not vary dependent on whether the machine is single user or not. Matt > -----Original Message----- > From: Ken Stox [mailto:stox@enteract.com] > Sent: Friday, April 13, 2001 12:40 PM > To: Matt Simerson > Subject: Re: Quota reporting is inaccurate. > > > > If memory serves correct, I think you will find quota reports 512byte > block, not 1k blocks. > > On Fri, 13 Apr 2001, Matt Simerson wrote: > > > I have an streaming server that does a mere three things in > life. It accepts > > FTP connections from users with local accounts and streams > the files back > > via Real streaming server or Darwin Streaming Server. > That's it, other than > > some log file processing and backups, that's all this machine does. > > > > In the last 8 months of service, a few anomolies related to > quotas have > > popped up. Every time it happens, the quota mechanism > reports that the user > > is using more space than they really are. I've dug through > the mailing list > > archives and found another user with this same problem so > I'm going to add a > > little fuel that fire and hope a resolution to this can be found. > > > > On this machine all users get a fixed quota size which they > are obliged not > > to exceed. Quota's are set up as follows: > > > > real1# more /etc/fstab > > # Device Mountpoint FStype Options > Dump > > Pass# > > /dev/mlxd0s1b none swap sw > 0 > > 0 > > /dev/mlxd0s1a / ufs rw > 1 > > 1 > > /dev/mlxd1s1e /usr ufs > rw,userquota 2 > > 2 > > /dev/mlxd0s1e /var ufs rw > 2 > > 2 > > proc /proc procfs rw > 0 > > 0 > > > > Quotas are enabled at boot time: > > > > real1# grep quota /etc/rc.conf > > enable_quotas="YES" > > > > For the most part, quota's work just fine. I build this > machine on FreeBSD > > 4.1.1-STABLE shortly after 4.1.1 was released. The server > has been humming > > along, doing it's streaming thing quite nicely. It's only > reboot in the last > > 8 months was last month when I upgraded from 4.1.1 to > 4.2-STABLE (4.3-BETA) > > hoping for a fix to the quota problem. FTP connections are > chrooted to the > > users home directory so the user cannot write files outside > it. We can see > > how much space is in use as follows: > > > > real1# du -d1 ~dahl > > 190827 /usr/home/dahl > > > > So the user is only using 190MB of space on /usr. We can > verify this by > > checking the entire /usr filesystem and verifying all > results are in ~dahl > > which I have done as follows: > > > > real1# find /usr -user dahl > > > > So, the only files owned by dahl that exist live in his home dir as > > expected. Doing a long list on the files confirms the file > sizes and du's > > count of 190MB: > > > > real1# ll ~dahl > > total 190826 > > -rw-r--r-- 1 dahl user 628 Mar 27 15:10 .cshrc > > -rw-r--r-- 1 dahl user 299 Mar 27 15:10 .login > > -rw-r--r-- 1 dahl user 160 Mar 27 15:10 .login_conf > > -rw------- 1 dahl user 371 Mar 27 15:10 .mail_aliases > > -rw-r--r-- 1 dahl user 331 Mar 27 15:10 .mailrc > > -rw-r--r-- 1 dahl user 722 Mar 27 15:10 .profile > > -rw------- 1 dahl user 276 Mar 27 15:10 .rhosts > > -rw-r--r-- 1 dahl user 852 Mar 27 15:10 .shrc > > -rwxr-xr-x 1 dahl user 108 Mar 27 15:10 .xinitrc > > -rwxr-xr-x 1 dahl user 108 Mar 27 15:10 .xsession > > -rw-r--r-- 1 dahl user 35826182 Apr 9 20:26 Mon040901.rm > > -rw-r--r-- 1 dahl user 47932775 Apr 9 12:03 Phish.rm > > -rw-r--r-- 1 dahl user 35451065 Apr 10 17:33 Tue041001.rm > > -rw-r--r-- 1 dahl user 37613531 Mar 30 17:40 best0f5.rm > > -rw-r--r-- 1 dahl user 38383851 Mar 30 08:17 bestof4.rm > > > > We verify our quota settings noting that quota's think that > dahl is using > > 345MB when in reality it should be reporting 190MB: > > > > real1# quota dahl > > Disk quotas for user dahl (uid 4639): > > Filesystem blocks quota limit grace files > quota limit > > grace > > /usr 345659 358400 358400 21 > 1000 2000 > > > > > > OK, so somehow our quota consistency got maligned. Running > quotacheck should > > fix this right? So, we run quotacheck on our /usr filesystem: > > > > real1# quotacheck -v /usr > > *** Checking user quotas for /dev/mlxd1s1e (/usr) > > unknown uid: 1751 > > root fixed: blocks 2508870 -> 2508868 > > real fixed: blocks 197062 -> 197046 > > > > So, quotacheck doesn't discover or fix the discrepancy. :-( > > > > Any ideas why this behavior would occur? Better yet, any > idea how to fix > > it? > > > > Matt > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message