tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Possible issue with fsck_ffs ?



I'm sure we have some experts who could figure this out a lot more quickly than me fumbling through the sources.... :)

At my $DAYJOB we have seen instances where newfs(8) can generate a filesystem with "fragments per cylinder-group" can exceed 0x10000. When newfs(8) stores the value in the file-system's superblock, it works correctly since fs_fpg is a 32-bit integer. However, newfs(8) also stores the value in the partition table's p_cpg member, which is only 16-bits. Values above 0x10000 will, obviously, get truncated.

fsck_ffs(8) works just fine as long as we are able to read the primary superblock. But if we're unable to access the primary SB, we need to use the p_cpg value to find the alternate superblocks, and because of the truncation noted above the search for alternates will fail.

Is there someone who can check/inspect NetBSD to see if we suffer from this possible truncation?

(Please cc me on responses, as I'm not subscribed to tech-userlevel)




-------------------------------------------------------------------------
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:       |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com    |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |                          | pgoyette at netbsd.org  |
-------------------------------------------------------------------------


Home | Main Index | Thread Index | Old Index