Date: Sat, 25 Mar 2006 00:48:07 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Nicolas KOWALSKI <Nicolas.Kowalski@imag.fr> Cc: freebsd-fs@FreeBSD.org Subject: Re: quotas problem on 4.11/UFS Message-ID: <20060325004132.P7231@epsplex.bde.org> In-Reply-To: <vqok6ak56sx.fsf@corbeau.imag.fr> References: <vqohd5pzezu.fsf@corbeau.imag.fr> <20060324194552.J6509@epsplex.bde.org> <vqok6ak56sx.fsf@corbeau.imag.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 24 Mar 2006, Nicolas KOWALSKI wrote: > Bruce Evans <bde@zeta.org.au> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060325004132.P7231>