Was trying to map out some bad blocks prior to temporarily read/empty 4 Tbyte volume using badsect(8) - and returing it. Was expecting to be able to put the sector # into badsect (e.g. 3432631424 from below FSCK output). This gave me a bit of an odd: badsect: 3432631424: Result too large As the daddr_t seems to be a 64bit unsigned; I assumed that the: number = strtol(*argv, NULL, 0); was some legacy culprint - and changed it to a strtoll as the daddr_t you are entering is an int 64. number = strtoll(*argv, NULL, 0); That gets it past that point; only to segv out on: cg = dtog(fs, fsbn); /usr/include/ufs/ffs/fs.h:#define dtog(fs, d) ((d) / (fs)->fs_fpg) /usr/include/ufs/ffs/fs.h:#define dtogd(fs, d) ((d) % (fs)->fs_fpg) a bit later. While fs is valid - it seems fs->fs_fpg returns as 0 why is this ? Is geom too new ? Or is badsect too old/retired ? Dw. aacd1: hard error cmd=read 4246326690-4246326721 . fsck(8):... THE FOLLOWING DISK SECTORS COULD NOT BE READ: 3432631424, 3432631425, 3432631426, 3432631427, 3432631428, 3432631429, 3432631430, 3432631431, 3432631432, 3432631433, 3432631434, 3432631435, 3432631436, 3432631437, 3432631438, 3432631439, 3432631440, 3432631441, 3432631442, 3432631443, 3432631444, 3432631445, 3432631446, 3432631447, 3432631448, 3432631449, 3432631450, 3432631451, 3432631452, 3432631453, 3432631454, 3432631455, $sudo geom label list aacd0s1d Geom name: aacd0s1d Providers: 1. Name: ufsid/4a08af657f7e3930 Mediasize: 4544528384 (4.2G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 536903168 Mode: r0w0e0 secoffset: 0 offset: 0 seclength: 8876032 length: 4544528384 index: 0 Consumers: 1. Name: aacd0s1d Mediasize: 4544528384 (4.2G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 536903168 Mode: r0w0e0 Fix: See above strtoll change -- but that uncovers another odd issue. How-To-Repeat: Run badsect with a >32 bit number. Observe it giving a Result too large
badsect's ABI uses mknod() and dev_t so it can only work up to 32 bits. (Before 4.4BSD, dev_t was only 16 bits, so badsect only works up to 16 bits. That is a whole 65536 sectors, or 33MB with 512-blocks. This was almost enough in 1980. However, the limit is on fs-blocks (fragments), not on 512-blocks, so the limit can be expanded a bit. With the current default ffs block size of 32K, the fragment size is 4K, so the limit in 1984 would have been 256MB. However, the default fragment size was 512 until about 1995.) It also has bugs in its error checking, so it only works up to 31 bits on arches with 32-bit longs. The above is one of them. 3432631424 doesn't fit in 31 bits, but it does fit in 32 bits. The bugs in the error checking are more serious than I thought, since the limit is on 512-blocks. So on arches with 32-bit longs, the limit on the file system size is 2**31 * 2**9 = 1TB. With 4K-frags it should be 2**32 * 2**12 = 16TB, so badsect should actually work on your 4TB file system. It shouldn't be expected to work. 4TB disks are supposed to be replaced if they have a single uncorrectable error. There are related limits on file system size from the file system itself. ffs1 uses 32-bit signed block (fragment) numbers internally, so it shouldn't be affected by the 332-bit badsect ABI limit. > As the daddr_t seems to be a 64bit unsigned; I assumed that the: daddr_t is 64 bits signed. > > number = strtol(*argv, NULL, 0); > > was some legacy culprint - and changed it to a strtoll as the daddr_t you are entering is an int 64. daddr_t used to be 32-bit signed, and badsect hasn't been maintained since before daddr_t became 64 bits. Even 1GB disks are supposed to be replaced if they have a single uncorrectable error. > number = strtoll(*argv, NULL, 0); Ugh. Long long should never be used. Use intmax_t. badsect's buggy error checking involves many type errors. It uses the system type daddr_t for 'number'. This is correct. But it also uses long, and in the above, long long, and in the clean version, intmax_t, for initializing 'number'. I neglected to fix this when I updated badsect from 16 bits to 32 bits in 1995. The update was incomplete. The result of strtoimax() should be assigned to a variable of type intmax_t. It shouldn't be assigned to 'number' before checking that it fits. The type errors continue with badsect abusing daddr_t for the disk block number. That was as correct as possible in 1994, and also in my fixes, because ffs also used this wrong type internally. ffs now uses ufs_daddr1_t and ufs_daddr_t internally. daddr_t would work in badsect since it is 64 bits signed and only 32 bits unsigned is needed, but it is logically wrong. > That gets it past that point; only to segv out on: > > cg = dtog(fs, fsbn); > > /usr/include/ufs/ffs/fs.h:#define dtog(fs, d) ((d) / (fs)->fs_fpg) > /usr/include/ufs/ffs/fs.h:#define dtogd(fs, d) ((d) % (fs)->fs_fpg) > > a bit later. While fs is valid - it seems fs->fs_fpg returns as 0 why is this ? Is geom too new ? Or is badsect too old/retired ? I don't see why that doesn't work. fsdb is the fs-block (frag) number, and the types are now large enough although logically wrong. Some of the differences for ffs2 are in macros, but the above macros are too simple to depend on the ffs version. Maybe libufs messes up the initialization of all of 'fs'. > aacd1: hard error cmd=read 4246326690-4246326721 > . > > fsck(8):... > THE FOLLOWING DISK SECTORS COULD NOT BE READ: 3432631424, 3432631425, 3432631426, 3432631427, 3432631428, 3432631429, 3432631430, 3432631431, 3432631432, 3432631433, 3432631434, 3432631435, 3432631436, 3432631437, 3432631438, 3432631439, 3432631440, 3432631441, 3432631442, 3432631443, 3432631444, 3432631445, 3432631446, 3432631447, 3432631448, 3432631449, 3432631450, 3432631451, 3432631452, 3432631453, 3432631454, 3432631455, Perhaps too many for badsect. I haven't used badsect recently, but spent a lot of time rearranging whole partitions on a laptop drive to avoid a 20GB area with a few bad sectors. The rest of the disk worked suprisingly well. Bruce
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped