From owner-freebsd-current@FreeBSD.ORG Tue May 6 16:59:54 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 996AE37B401 for ; Tue, 6 May 2003 16:59:54 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE4D943F75 for ; Tue, 6 May 2003 16:59:50 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id JAA29404; Wed, 7 May 2003 09:59:37 +1000 Date: Wed, 7 May 2003 09:59:35 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Julian Elischer In-Reply-To: Message-ID: <20030507092200.Y18314@gamplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: FreeBSD current users Subject: Re: 'oddness' for BIG filesystems.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 23:59:54 -0000 On Tue, 6 May 2003, Julian Elischer wrote: > ... > biggie# df /junk > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/da2p1 -2125157230 2 1996225260 0% /junk > > hmmmmm -2125157230? obviously a 32 bit number in there somewhere.. > > :-) >From : %%% struct statfs { long f_spare2; /* placeholder */ long f_bsize; /* fundamental filesystem block size */ long f_iosize; /* optimal transfer block size */ long f_blocks; /* total data blocks in filesystem */ long f_bfree; /* free blocks in fs */ long f_bavail; /* free blocks avail to non-superuser */ ... }; %%% So statfs(2) is incapable of returning more that 32 bits for block counter without changing its binary interface. Large block counts apparently get silently truncated somewhere in the kernel. statvfs(3) supports 64-bit block counts, but since it is implemented using statfs(2) it inherits bugs from the latter. > Prior to this I did the same but upon mounting the filesystem > /junk disappeared. it showed up in 'df' and 'mount' but > it didnt't appear in / and there was no way to access it. > It was not possible to unmount it. > > I was forced to reboot. I have not seen it so far this session > but if anyone else has a large filesystem they may keep an eye > open for this wierdness. Is this with ufs2? ufs1 has an overflow bug in fstobdb() for file systems larger than 1TB. Fix: %%% Index: fs.h =================================================================== RCS file: /home/ncvs/src/sys/ufs/ffs/fs.h,v retrieving revision 1.38 diff -u -2 -r1.38 fs.h --- fs.h 10 Jan 2003 06:59:34 -0000 1.38 +++ fs.h 27 Apr 2003 17:40:14 -0000 @@ -490,5 +490,5 @@ * This maps filesystem blocks to device size blocks. */ -#define fsbtodb(fs, b) ((b) << (fs)->fs_fsbtodb) +#define fsbtodb(fs, b) ((daddr_t)(b) << (fs)->fs_fsbtodb) #define dbtofsb(fs, b) ((b) >> (fs)->fs_fsbtodb) %%% This causes various problems, including unmount failures as a side effect of not detecting the preposterous (negative) block numbers that can be generated by the overflow. Bruce