From owner-freebsd-questions@FreeBSD.ORG Tue Aug 29 16:55:56 2006 Return-Path: X-Original-To: FreeBSD-questions@FreeBsd.org Delivered-To: FreeBSD-questions@FreeBsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3973916A4E0 for ; Tue, 29 Aug 2006 16:55:56 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB46E43D46 for ; Tue, 29 Aug 2006 16:55:50 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id BCFE05D87; Tue, 29 Aug 2006 12:55:49 -0400 (EDT) X-Virus-Scanned: amavisd-new at codefab.com Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwxVXV1I10HM; Tue, 29 Aug 2006 12:55:48 -0400 (EDT) Received: from [192.168.1.251] (pool-68-161-96-195.ny325.east.verizon.net [68.161.96.195]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id 4BB9D5D68; Tue, 29 Aug 2006 12:55:48 -0400 (EDT) Message-ID: <44F4718F.1010502@mac.com> Date: Tue, 29 Aug 2006 12:55:43 -0400 From: Chuck Swiger User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Can Sar References: <34A15B01-CECC-478F-8EE8-3AEA839803C7@stanford.edu> In-Reply-To: <34A15B01-CECC-478F-8EE8-3AEA839803C7@stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-questions@FreeBsd.org Subject: Re: UFS2 fsck Question (semantics of -p) 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: Tue, 29 Aug 2006 16:55:56 -0000 Can Sar wrote: [ ... ] > Would you consider it an error if the -p option does not fix > inconsistencies caused by a simple power failure, without any hardware > or software corruption? You're asking an interesting question, but the issue of data integrity depends not only on the software which comprises the OS, but also on the hardware being used. In particular, the system depends upon the hard drives to reliably report when data being written actually has been; SCSI drives, using tagged command queuing, especially in conjunction with a battery-backup which ensures the drive stays up long enough to flush it's write cache even if system power is removed, will tend to fare pretty well. IDE drives, by contrast, have a bad habit of lying about whether data has actually been written to the disk itself rather than simply making it to the write cache on the drive. (Such drives ignore the ATA "FLUSH CACHE" command, specificly.) In other words, showing that a filesystem can become inconsistent in a fashion that "fsck -p" cannot correct is interesting and a concern regardless of the circumstances, but showing it in cases where you are using battery-backed drives and/or SCSI rather than IDE is a lot more meaningful. If you are using IDE devices, your testing will be more meaningful if you disable the IDE write-cache entirely. Also, you should put your results somewhere, perhaps on a webpage with links to the filesystem images and a complete dmesg so that the OS version and hardware being used is well-documented. -- -Chuck