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