From owner-freebsd-bugs Thu Jan 2 09:05:21 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id JAA14515 for bugs-outgoing; Thu, 2 Jan 1997 09:05:21 -0800 (PST) Received: (from mpp@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id JAA14503; Thu, 2 Jan 1997 09:05:16 -0800 (PST) From: Mike Pritchard Message-Id: <199701021705.JAA14503@freefall.freebsd.org> Subject: Re: kern/2325: quota.user enlarged, no boot on 2.2-BETA To: bde@zeta.org.au (Bruce Evans) Date: Thu, 2 Jan 1997 09:05:15 -0800 (PST) Cc: freebsd-bugs@freefall.freebsd.org In-Reply-To: <199612302352.KAA14147@godzilla.zeta.org.au> from "Bruce Evans" at Dec 31, 96 10:52:03 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Bruce Evans wrote: > > [...] > Here the id is unsigned long and the struct has size 64, so these > calculations overflow when the id is >= 2^26 (67108864). The sparse > file would need to be at least 256GB instead of a measly 4GB to > correctly support id 0xffffffff. The overflow probably causes id > 2^26 to be an alias for id 0. There is probably no problem except > for the time that it takes to initialize the 4GB or 256GB file. You > are unlikely to have any aliases for 0 or -2 (really 0xfffffffe). The trouble is, that once you have this huge quota file, quotacheck must examine the entire file looking for quota entries that need to be reset. E.g. it currently has no way of knowing that there are no quota structures in use bewtween the last real uid and 0xfffffffe - it checks each and every one of them, and even though I addded some code to speed this up, it still can take an unacceptable amount of time to process the qouta file. I do have a couple of ideas on how to totally avoid this problem, and as soon as I figure out the way to do this with the least amount of impact on current quota users, I'll go ahead and implement it. -- Mike Pritchard mpp@FreeBSD.org "Go that way. Really fast. If something gets in your way, turn"