Date: Fri, 7 Jul 2006 22:56:47 -0400 (EDT) From: Charles Sprickman <spork@bway.net> To: freebsd-stable@freebsd.org Subject: 6.1 quota issues Message-ID: <Pine.OSX.4.61.0607072227510.3261@white.nat.fasttrackmonkey.com>
next in thread | raw e-mail | index | archive | help
Hello all,
I'm in the process of rolling out a new shell server and for numerous
reasons have decided 6.x is the best fit (jail improvements, SMP
improvements, 3Ware driver, pf). The shell server is within a jail, and
the uids there are unique so that quotas remain sane. There are about
5000 active accounts using about 40GB of a 210GB partition. The
quota.user file is about 4GB.
I just started work on getting quotas setup for everyone after rsyncing
all the homedirs from the old server over. At first, all seemed well,
then I ran into a few issues on subsequent rsyncs. I had people with
large (1GB+) homedirs and quotas in the 1GB-4GB range and as rsync was
chowning the files to the users it was throwing errors about "quota
exceeded". Here's a brief example that illustrates what I was seeing:
ot@beta[/home/staff/micro/tmp]# quota micro
Disk quotas for user micro (uid 5315):
Filesystem usage quota limit grace files quota limit grace
/ 1630026 3000000 3100000 13393 0 0
root@beta[/home/staff/micro/tmp]# chown micro index.html
chown: index.html: Disc quota exceeded
root@beta[/home/staff/micro/tmp]#
I know in the past when I've seen inconsistencies indicating that I needed
a manual run of quotacheck, they would show up in the output of the quota
command; ie: the "quota" command would show the user had more usage than
"du" would indicate. The above example is a bit odd - "quota" shows that
he's well within his limits, but the kernel thinks otherwise.
Thinking it would be a good idea to stop the jails, turn off quotas,
umount the partition, fsck it, mount it and then run quotacheck, I found
more problems. My first run of quotacheck ran for a few minutes, reported
many inconsistencies and then sat there for quite some time before
spitting this out:
quotacheck: /jails/quota.user: seek failed: Invalid argument
Trying again, it reported the same inconsistencies then sat there for more
than an hour taking up all the available CPU on the box until I killed it.
The mtime on quota.user had not changed during the run.
Running it yet again now gives me this:
/jails: fixed: inodes 27 -> 0 blocks 156 -> 0
quotacheck: /jails/quota.user: seek failed: Invalid argument
THE FOLLOWING FILE SYSTEM HAD AN UNEXPECTED INCONSISTENCY:
/dev/twed0s1g (/jails)
For now I can live without quotas, but if there's anything I can test from
-stable that might address this I'd like to try it. I'd say this thing is
still a good month from going live since we have lots of dependancy mess
on the old box to clean up before cutting over.
Any ideas what's going on here? Is this related to the large number of
users and the size of the partition? I've seen some of the discussions
about snapshots + quotas, but that seems like an entirely different issue.
For the time being I've killed "background_fsck" and "check_quotas" in
rc.conf, and I'll avoid dumping that fs with the snapshot flag.
What other information can I provide to help better define where this bug
lives?
Thanks,
Charles
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.OSX.4.61.0607072227510.3261>