From owner-freebsd-stable@FreeBSD.ORG Thu Jan 29 16:19:01 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA59E1065673 for ; Thu, 29 Jan 2009 16:19:01 +0000 (UTC) (envelope-from matthias.andree@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 30CEB8FC1D for ; Thu, 29 Jan 2009 16:19:00 +0000 (UTC) (envelope-from matthias.andree@gmx.de) Received: (qmail invoked by alias); 29 Jan 2009 15:52:19 -0000 Received: from balu.cs.uni-paderborn.de (EHLO balu.cs.uni-paderborn.de) [131.234.21.37] by mail.gmx.net (mp001) with SMTP; 29 Jan 2009 16:52:19 +0100 X-Authenticated: #428038 X-Provags-ID: V01U2FsdGVkX193sON0bip3XF8nWjnqcPgkasWEqn0jLfZZgUf+/W 5cJbCFtuLpFDCe Received: from localhost ([127.0.0.1]) by balu.cs.uni-paderborn.de with esmtp (Exim 4.69) (envelope-from ) id KE8PF4-0004DW-C5 for freebsd-stable@freebsd.org; Thu, 29 Jan 2009 16:52:16 +0100 Message-ID: <4981D0B0.1060906@gmx.de> Date: Thu, 29 Jan 2009 16:52:16 +0100 From: Matthias Andree User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.19) Gecko/20081209 Thunderbird/2.0.0.19 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Subject: 7.1-RELEASE growfs/fsck_ffs woes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2009 16:19:02 -0000 Greetings, I have a hard time with file system access. Here's the story: I'd been unhappy about GEOM_JOURNAL within the same provider as my /usr and /var partitions (used JOURNAL on a fresh install), it would occasionally give up on fsync() for lock messups (FreeBSD 7.1-RELEASE-p2). Several weeks ago, I reverted my -o async journalled /var to softupdates without journal, with no ill effects. AFAIR, I installed with gjournal label with just one provider, and then newfs UFS2 with journal. Earlier today, I disabled the journal on /usr (shutdown to single user mode, dismount, gjournal sync, gjournal stop, gjournal clear, tunefs -J disable, kldunload geom_journal, fsck) - that worked, and fsck preen considered the FS clean. I tried to resize the partition to its full size with growfs; and it warned about being unable to allocate some 58,000 blocks, but performed the operation (i. e. I got a list of superblocks) - apparently it completed. A subsequent fsck -f however turned up with a gazillion of "DUP" blocks, in random places. I have no explanation for that; am currently running fsck -y. Accidentally, I ran growfs twice, but the second run didn't seem to do a lot - it just warned it couldn't allocate 58,600+ sectors and quit. I've also found that fsck_ffs's pass 1b is EXTREMELY slow, and from a cursory glance at pass1b.c, some none-scalable (as in O(n^2) or worse) effects seem to be at play. I'm currently away from the machine, but any insights on the growfs corruption and/or pass1b.c accelerators are welcome - ext2fsck is a lot faster when doing deep searches for duplicate blocks (pass 1b and pass 1c), but I haven't checked the code. The partition slice is several GB in size with default newfs settings, but not overly huge (<< 100 GB), and last time I checked, it had taken around 30 min for scanning 7 out of 78 (IIRC) cylinder groups. I hope fsck doesn't do more damage... ;-) This is an Athlon XP 2500+ (later "Barton" version with 512 kB L2 cache) with 1 GB of RAM and a reasonably fast Maxtor 250 GB SATA drive, with a reasonably fast fsck if pass1b isn't needed (perhaps two or three minutes). I've recompiled fsck_ffs with -O3 -march=athlon-xp to peep cycles, but compiler optimization cannot fix slow algorithms. Thanks in advance, Matthias