From owner-freebsd-fs@FreeBSD.ORG Fri Mar 24 13:48:11 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 D3C5716A401 for ; Fri, 24 Mar 2006 13:48:11 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3365343D45 for ; Fri, 24 Mar 2006 13:48:11 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87]) by mailout1.pacific.net.au (Postfix) with ESMTP id E0BF7347CB5; Sat, 25 Mar 2006 00:48:09 +1100 (EST) Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id k2ODm7qI017071; Sat, 25 Mar 2006 00:48:08 +1100 Date: Sat, 25 Mar 2006 00:48:07 +1100 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Nicolas KOWALSKI In-Reply-To: Message-ID: <20060325004132.P7231@epsplex.bde.org> References: <20060324194552.J6509@epsplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@FreeBSD.org 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:48:11 -0000 On Fri, 24 Mar 2006, Nicolas KOWALSKI wrote: > Bruce Evans writes: >> 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. >> ... > > 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. Perhaps it had them but there were none when you checked. I think the quota file doesn't shrink if slots at the end of int become unused. Files with a uid of -2 are created on nfs clients if root is not mapped and root creates a file. I see quite a lot of them due to having a world-writeable /c/tmp directory and using it as root on the client. Bruce