From owner-freebsd-questions@FreeBSD.ORG Sat Mar 12 22:20:07 2011 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D67A106566B for ; Sat, 12 Mar 2011 22:20:07 +0000 (UTC) (envelope-from peter@vereshagin.org) Received: from mx1.skyriver.ru (ns1.skyriver.ru [89.108.118.221]) by mx1.freebsd.org (Postfix) with ESMTP id 949BA8FC14 for ; Sat, 12 Mar 2011 22:20:06 +0000 (UTC) Received: from localhost (unknown [89.187.142.208]) by mx1.skyriver.ru (Postfix) with ESMTPSA id 532F15A80 for ; Sun, 13 Mar 2011 00:56:12 +0300 (MSK) Date: Sun, 13 Mar 2011 01:19:31 +0300 From: Peter Vereshagin To: freebsd-questions@freebsd.org Message-ID: <20110312221929.GA5335@external.screwed.box> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Organization: ' X-Face: 8T>{1owI$Byj]]a; ^G]kRf*dkq>E-3':F>4ODP[#X4s"dr?^b&2G@'3lukno]A1wvJ_L(~u 6>I2ra/<,j1%@C[LN=>p#_}RIV+#:KTszp-X$bQOj,K Subject: 'Fast' fsck -p coredumps on GPT volume? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2011 22:20:07 -0000 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@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: The data for partition 3 is: The data for partition 4 is: # 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