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. BruceReceived 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