On Thu, Jan 04, 2018 at 09:11:04AM +0100, Otto Moerbeek wrote:
> On Wed, Jan 03, 2018 at 09:44:55PM -0600, Colton Lewis wrote:
>
> > When I try to run fsck on partition m of this disk:
> >
> > # /dev/rsd1c:
> > type: SCSI
> > disk: SCSI disk
> > label: TOSHIBA MD04ACA4
> > duid: 8ad0895bc1395d21
> > flags:
> > bytes/sector: 512
> > sectors/track: 63
> > tracks/cylinder: 255
> > sectors/cylinder: 16065
> > cylinders: 486401
> > total sectors: 7814037168
> > boundstart: 262208
> > boundend: 7814037168
> > drivedata: 0
> >
> > 16 partitions:
> > # size offset fstype [fsize bsize cpg]
> > a: 1136000 262208 4.2BSD 2048 16384 8875
> > b: 1821490 1398208 swap
> > c: 7814037168 0 unused
> > d: 1571840 3219712 4.2BSD 2048 16384 12280
> > e: 2318784 4791552 4.2BSD 2048 16384 12958
> > f: 2672000 7110336 4.2BSD 2048 16384 12958
> > g: 1545856 9782336 4.2BSD 2048 16384 12077
> > h: 4944064 11328192 4.2BSD 2048 16384 12958
> > i: 262144 64 MSDOS
> > j: 2428672 16272256 4.2BSD 2048 16384 12958
> > k: 6954496 18700928 4.2BSD 2048 16384 12958
> > l: 7898912 25655424 4.2BSD 2048 16384 12958
> > m: 7780482560 33554560 4.2BSD 8192 65536 1
> >
> > fsck reports that it cannot read negative block numbers:
> >
> > ** /dev/rsd1m
> > BAD SUPER BLOCK: MAGIC NUMBER WRONG
> >
> > LOOK FOR ALTERNATE SUPERBLOCKS? yes
> >
> >
> > CANNOT READ: BLK 749213312
> > CONTINUE? yes
> >
> > THE FOLLOWING DISK SECTORS COULD NOT BE READ: 749213312, 749213313,
> > 749213314, 749213315, 749213316, 749213317, 749213318, 749213319,
> >
> > CANNOT READ: BLK -2147483648
> > CONTINUE? yes
> >
> > THE FOLLOWING DISK SECTORS COULD NOT BE READ: -2147483648,
> > -2147483647, -2147483646, -2147483645, -2147483644, -2147483643,
> > -2147483642, -2147483641, -2147483640, -2147483639, -2147483638,
> > -2147483637, -2147483636, -2147483635, -2147483634, -2147483633,
> >
> > ...<repeat for the rest of the disk>
> >
> > How can I make sure fsck can handle a partition this size? There is
> > nothing important on there at the moment.
> >
> > --
> > Sincerely,
> > Colton Lewis
>
> Did you actually newfs that partition? It looks like not since no
> superblock or alternative is found.
>
> That said, it looks like there's an overflow somehere. I do not have
> the hardware to investigate this though.
>
> On a side note: a partition that large will cause problem in other
> areas. Even if it would work, the memory needed to do an fsck will be
> huge.
>
> Also: provide dmeg! The platform involved can play a role in this.
>
> -Otto
I tried to reproduce your problem using a vnd image using a sparse
file.
If I do not newfs the device, I get results very similar to what you
are seeing.
If I newfs the partition first, an fsck -f works as expected. So without
further information, I assume you did not run newfs.
I'll invetstigate the negative block numbers.
-Otto
