From owner-freebsd-questions@FreeBSD.ORG Mon Aug 28 22:19:24 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 305E216A4DA for ; Mon, 28 Aug 2006 22:19:24 +0000 (UTC) (envelope-from csar@stanford.edu) Received: from smtp-roam.Stanford.EDU (smtp-roam.Stanford.EDU [171.64.10.152]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6871743D5E for ; Mon, 28 Aug 2006 22:19:23 +0000 (GMT) (envelope-from csar@stanford.edu) Received: from [171.66.34.152] (DNab422298.Stanford.EDU [171.66.34.152]) (authenticated bits=0) by smtp-roam.Stanford.EDU (8.12.11/8.12.11) with ESMTP id k7SMJLtj019750 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 28 Aug 2006 15:19:22 -0700 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <34A15B01-CECC-478F-8EE8-3AEA839803C7@stanford.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: FreeBSD-questions@FreeBsd.org From: Can Sar Date: Mon, 28 Aug 2006 15:19:17 -0700 X-Mailer: Apple Mail (2.752.2) Cc: Subject: 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: Mon, 28 Aug 2006 22:19:24 -0000 Hi, I work on a project to automatically (by dynamically running the system) find crash recovery errors in storage systems and we are beginning to do some preliminary checking of FreeBSD. We found an "error" where on power failure the disk can get corrupted even after an operation has returned successfully on a synchronous mount. Fsck running with the -p option cannot fix this error, while running it without, does happen to fix it (in this particular test case). However, the fsck manfile says the following: "The kernel takes care that only a restricted class of innocuous file sys- tem inconsistencies can happen unless hardware or software failures intervene. These are limited to the following: Unreferenced inodes Link counts in inodes too large Missing blocks in the free map Blocks in the free map also in files Counts in the super-block wrong These are the only inconsistencies that fsck_ffs with the -p option will correct; if it encounters other inconsistencies, it exits with an abnor- mal return status and an automatic reboot will then fail. For each cor- rected inconsistency one or more lines will be printed identifying the file system on which the correction will take place, and the nature of the correction. After successfully correcting a file system, fsck_ffs will print the number of files on that file system, the number of used and free blocks, and the percentage of fragmentation." 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? I have two example ufs2 images of such errors that you can download. http://keeda.stanford.edu/ufs-umount-image http://keeda.stanford.edu/ufs-mount-sync-image Thank you very much for your help, Can Sar