'Fast' fsck -p coredumps on GPT volume?

[Peter Vereshagin]

Hey freebsd-questions don't wanna cause you pain but the big boys feel no sorrow!

I have fsck -p -y coredump on every cold reboot.
The only unusual things to cause this are: it's a GPT volume and the nullfs is used extensively.
I think this is because of the the GPT because I can't geom_label on that UFS1+J volume, but I can use geom_label on an 'unjournalled' ad1p4 partition.
Of course I use geom_label for / and it has no journal.

The setup is:

  $ uname -a
  FreeBSD screwed.box 7.4-PRERELEASE FreeBSD 7.4-PRERELEASE #8: Thu Feb 17 13:03:24 MSK 2011     toor at screwed.box:/usr/local/obj/usr/local/src/sys/JUICY  i386
  # fdisk /dev/ad1
  ******* Working on device /dev/ad1 *******
  parameters extracted from in-core disklabel are:
  cylinders=155061 heads=16 sectors/track=63 (1008 blks/cyl)
  
  Figures below won't work with BIOS for partitions not in cyl 1
  parameters to be used for BIOS calculations are:
  cylinders=155061 heads=16 sectors/track=63 (1008 blks/cyl)
  
  Media sector size is 512
  Warning: BIOS sector numbering starts with sector 1
  Information from DOS bootblock is:
  The data for partition 1 is:
  sysid 238 (0xee),(EFI GPT)
      start 1, size 156301487 (76319 Meg), flag 80 (active)
          beg: cyl 0/ head 1/ sector 1;
          end: cyl 1023/ head 255/ sector 63
  The data for partition 2 is:
  <UNUSED>
  The data for partition 3 is:
  <UNUSED>
  The data for partition 4 is:
  <UNUSED>
  # gpart show ad1
  =>       34  156301421  ad1  GPT  (75G)
           34        128    1  freebsd-boot  (64K)
          162    2999729    2  freebsd-ufs  (1.4G)
      2999891    7000000    3  freebsd-swap  (3.3G)
      9999891  146301564    4  freebsd-ufs  (70G)
  # gjournal list 
  Geom name: gjournal 1645160533
  ID: 1645160533
  Providers:
  1. Name: ad1p4.journal
     Mediasize: 73832658432 (69G)
     Sectorsize: 512
     Mode: r1w1e1
  Consumers:
  1. Name: ad1p4
     Mediasize: 74906400768 (70G)
     Sectorsize: 512
     Mode: r1w1e1
     Jend: 74906400256
     Jstart: 73832658432
     Role: Data,Journal
  # dumpfs -m /usr/local   
  # newfs command for /usr/local (/dev/ad1p4.journal)
  newfs -L mess00 -O 1 -a 16 -b 8192 -d 8192 -e 1024 -f 1024 -g 16384 -h 128 -m 8 -o time -s 144168960 /dev/ad1p4.journal 
  # df -hi /usr/local 
  Filesystem            Size    Used   Avail Capacity iused ifree %iused  Mounted on
  /dev/ad1p4.journal     67G     58G    3.1G    95%    2.0M   16M   11%   /usr/local
  # wc -l < /etc/fstab
       242

so it's enough to know that ad1p4.journal is an /usr/local.
Should I place /tmp on a different volume for 'fast' fsck -p feature? It's a symlink by now:
tmp -> var/tmp and var -> /usr/local/var
I see nothing I can use for a guess about a fsck_ufs segfault. The dumps and a core are there:

  http://119out.smtp.ru/kdump.out
  http://119out.smtp.ru/ktrace.out
  http://119out.smtp.ru/truss.out
  http://119out.smtp.ru/_fsck_ufs.core.gz

The cold reboot is caused by cpu overheating and I'm absolutely sure of other parts of hardware, especially the HDD. I just made a cpu more silent ( and sometimes hot ). But typically it happens when sound outputs from the c-media built-in.
fsck -y has no problems and lost+founds are typically only a few inodes, may be 5.
I tried with unionfs on a volume in a past but I believe I wiped the whiteouts out since then.
The only fsck -p passed I saw after cold reboot were when I believe all of the files open on that volume were open read-only.

Many thanks for any hints, clues and ideas on all of that. Should I file a PR better?

73! Peter pgp: A0E26627 (4A42 6841 2871 5EA7 52AB  12F8 0CE1 4AAC A0E2 6627)
--
http://vereshagin.org