Re: 'oddness' for BIG filesystems..

From: Bruce Evans <bde_at_zeta.org.au>
Date: Wed, 7 May 2003 09:59:35 +1000 (EST)
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 <sys/mount.h>:

%%%
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
_at__at_ -490,5 +490,5 _at__at_
  * 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
Received on Tue May 06 2003 - 14:59:54 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:06 UTC