From owner-freebsd-fs@FreeBSD.ORG Thu Jul 22 13:02:24 2010 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 910621065672 for ; Thu, 22 Jul 2010 13:02:24 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 512708FC1D for ; Thu, 22 Jul 2010 13:02:24 +0000 (UTC) Received: by iwn35 with SMTP id 35so9982215iwn.13 for ; Thu, 22 Jul 2010 06:02:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=umKXl8c41mYoIPeRgRhSZyDLMTlcNGGXyts6k/XR468=; b=E7dBXIh+PrursQSdVNnl+MCLF5eEQJd4+GnbMAuwaRtToUWZ+ChCGx7QOUQOBaMwGg GQXc1NDkwXbzSGv9PP9tZjbm9xMF1x7kw2bpw2b+/ueuLDGPYxKZK9cOqjaiQmNbebYi I78hcc2XD856EN3Kh/kV1W61oCzqZ2HXW1eV8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=JLrEDnF2xW3b7FSdBOr7a6L1MKFKglBRlpO4qvzwVkwVlW0DnTxWKKgQE8xl0KLYep DrV8qPZ1zVucqzalPzR31XBNAHRbX3PIhLgm2ZYZNwqKOeucWwtrMO+UtZkEOPH8bM9Q +5Q3SjvxZYguKa10oPg2Q1VGirCcX7J9axdoU= Received: by 10.231.159.203 with SMTP id k11mr1837907ibx.115.1279803743427; Thu, 22 Jul 2010 06:02:23 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-133-55.dsl.klmzmi.sbcglobal.net [99.181.133.55]) by mx.google.com with ESMTPS id e8sm29962634ibb.20.2010.07.22.06.02.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 22 Jul 2010 06:02:21 -0700 (PDT) Sender: "J. Hellenthal" Date: Thu, 22 Jul 2010 09:02:14 -0400 From: jhell To: Kirk McKusick In-Reply-To: <201007212015.o6LKFp9Y066176@chez.mckusick.com> Message-ID: References: <201007212015.o6LKFp9Y066176@chez.mckusick.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "Mikhail T." , fs@freebsd.org Subject: Re: background fsck considered harmful? (Re: panic: handle_written_inodeblock: bad size) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 13:02:24 -0000 On Wed, 21 Jul 2010 16:15, Kirk McKusick wrote: In Message-Id: <201007212015.o6LKFp9Y066176@chez.mckusick.com> >> Date: Tue, 20 Jul 2010 12:48:58 -0400 >> From: "Mikhail T." >> To: Kirk McKusick >> CC: Jeremy Chadwick , fs@freebsd.org >> Subject: background fsck considered harmful? (Re: panic: handle_written_inodeblock: >> bad size) >> X-ASK-Info: Message Queued (2010/07/20 09:49:10) >> X-ASK-Info: Confirmed by User (2010/07/20 10:28:39) >> >> 20.07.2010 11:44, Kirk McKusick ???????(??): >>> Adding it to all the panic's will be a lot of work, >>> but I agree would be useful. I will look into doing so when I >>> get a chance. >>> >>> Kirk McKusick >>> >> How about disabling background fsck in a default install? It seems to >> be the consensus here, that my troubles were due to fsck not fixing the >> file-system properly reboot after reboot... >> >> Yours, >> >> -mi > > Certainly disabling background fsck will eliminate that from your > possible set of issues and may prevent a recurrance. It does mean that > after a crash you will have to wait while your filesystems are checked > before your system will come up. If your filesystems are below 0.5Tb > that should be tolerable. > This had me thinking of a possibility to have fsck write & read some meta-data to/from the disk its checking, say an enumerated value somewhere between 1 & 10, whatever would be acceptable. When it would hit this highest predetermined (hard coded) value fsck could return an error code that could be parsed by an rc script to change its behavior to a full check. But along those lines of thinking maybe fsck already returns something like this ? and if so does it do this early enough for a script to catch it ? This ultimately would remove the need to have a background_fsck_enable variable. And would allow for some file-systems to be checked in the background without user intervention while others would be checked in the foreground. And then thinking again maybe this could be handled by the initiating script that sets a variable that's held until the system is writable to be stored somewhere on-disk after the system is up so it could be read the next time around. Personally I prefer the previous as it seems to be a stronger solution. > The longer term solution is to use journaled soft updates when they > become available in 9.0. > > Kirk McKusick > Regards, -- jhell