On Wed, 12 Nov 2014, Nikos Skalkotos wrote: > Hello, here is the complete output:
okay, fdisk output and disklabel output look sane and match up. The diff of the dumpfs output is interesting: -^magic 11954 (FFS1) time Wed Nov 12 10:13:55 2014 +^magic 11954 (FFS1) time Wed Nov 12 10:19:09 2014 -ncg 6 ncyl 6 size 522096 blocks 512247 +ncg 505 ncyl 505 size 52350320 blocks 51522108 -nbfree 36554 ndir 1011 nifree 141082 nffree 208 +nbfree 6412786 ndir 1011 nifree 13107098 nffree 213 -csaddr 1648 cssize 2048 +csaddr 1648 cssize 8192 Note the cssize (cylinder summary size) has grown but csaddr hasn't changed. That means it probably had to relocate allocated blocks. This being your root disk, it may have relocated blocks in /boot, which would require re-running installboot. (FreeBSD has actually deleted the code to support that and made their growfs always relocate the cylinder summary to the first of the new cylinder groups; we may want to do that too; moving allocated blocks around is a nasty wart.) There may also be bugs around growfs assuming the new area is zero-filled, which it might not be. It may be a good test to try zeroing the new area with dd before running growfs and see if that makes it behave correctly. > uvm_fault(0xffffffff81d97be0, 0xffffffff8d2a5811, 0, 2) -> e > kernel: page fault trap, code=0 > Stopped at worklist_print+0x26b: addb %al,acpi_pdirpa+0xbfeeac0 > ddb> trace > worklist_print() at worklist_print+0x26b > ffs_init() at ffs_init+0xa4 > vfs_register() at vfs_register+0x94 > vfsinit() at vfsinit+0x80 > main() at main+0x457 > end trace frame: 0x0, count: -5 > ddb> That's an odd place to crash, having nothing to do with the filesystem itself; that's just where it hooks in the code to support FFS filesystems at all. Being not directly related makes me wonder if growfs is corrupting your kernel by its relocating of blocks from the first cylinder group... Philip Guenther
