From owner-freebsd-fs@FreeBSD.ORG Fri Mar 24 13:08:36 2006 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A39816A41F for ; Fri, 24 Mar 2006 13:08:36 +0000 (UTC) (envelope-from Nicolas.Kowalski@imag.fr) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 574E743D49 for ; Fri, 24 Mar 2006 13:08:35 +0000 (GMT) (envelope-from Nicolas.Kowalski@imag.fr) Received: from mail-veri.imag.fr (mail-veri.imag.fr [129.88.43.52]) by imag.imag.fr (8.13.0/8.13.0) with ESMTP id k2OD8V6n016927 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 24 Mar 2006 14:08:31 +0100 (CET) Received: from corbeau.imag.fr ([129.88.43.162]) by mail-veri.imag.fr with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1FMm1n-0005KV-OJ for freebsd-fs@FreeBSD.org; Fri, 24 Mar 2006 14:08:31 +0100 Received: from kowalski by corbeau.imag.fr with local (Exim 4.50) id 1FMm1m-0006V9-Om for freebsd-fs@FreeBSD.org; Fri, 24 Mar 2006 14:08:30 +0100 To: freebsd-fs@FreeBSD.org References: <20060324194552.J6509@epsplex.bde.org> From: Nicolas KOWALSKI Date: Fri, 24 Mar 2006 14:08:30 +0100 In-Reply-To: <20060324194552.J6509@epsplex.bde.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Nicolas Kowalski X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (imag.imag.fr [129.88.30.1]); Fri, 24 Mar 2006 14:08:31 +0100 (CET) X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-Information: Please contact the ISP for more information Cc: Subject: Re: quotas problem on 4.11/UFS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2006 13:08:36 -0000 Bruce Evans writes: > On Thu, 23 Mar 2006, Nicolas KOWALSKI wrote: > >> Our FreeBSD 4.11 fileserver (NFS, Samba) seems to have some problems >> with quotas, apparently just after a lot of files are deleted. The >> clients are mostly Linux 2.6 workstations (75), and some Windows XP >> (10). >> >> For example, yesterday the quota files of one disk were these: >> >> -rw-r----- 1 root tty 2097120 Mar 21 23:14 quota.group >> -rw-r----- 1 root tty 2097120 Mar 21 23:14 quota.user >> >> >> But today, after a user deleted a lot of his files, the quotas files >> are: >> >> -rw-r----- 1 root tty 2097120 Mar 22 23:10 quota.group >> -rw-r----- 1 root tty 4294967264 Mar 22 23:10 quota.user > > IIRC, quota maps are sparse, with uid N mapped to offset > N*sizeof(somestruct). With 32-bit uids, N can be as large as > 4294967295, so the file size wants to be (this+1)*sizeof(somestruct) = > some not very large multiple of 4GB. The large file sizes for this > might even work, without wasting much disk space, since files can be > sparse too, but there may be overflow problems at 4G. > > Your magic size of 4294967264 is 4G-32. 4G-2 is a common large uid; > it is produced by nfs's default mapping of the root uid (nfs spells > this id bogusly as -2, but uids are unsigned so it becomes a very > large unsigned value (but "very large" is only 65334 with 16-bit > uids)). Your magic file size would be explained by > sizeof(somestruct) being 32 and the magic uid N = (uint32_t)-2 being > used. Then (N+1)*sizeof(somestruct) gives 4G-32 after overflow in > the multiplication. Many thanks for this explanation. However, the filesystem does not have any files belonging to some user with a large or -2 uid. I checked it, and even "quotacheck -v" does not show anything like that; our current uids goes from 0 to 6000 max, and only these appear in the repquota result. -- Nicolas