From owner-freebsd-fs@FreeBSD.ORG Fri Dec 7 12:48:22 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 968BA16A420 for ; Fri, 7 Dec 2007 12:48:22 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 435D513C442 for ; Fri, 7 Dec 2007 12:48:22 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id D406A2085; Fri, 7 Dec 2007 13:48:12 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.1/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 585322082; Fri, 7 Dec 2007 13:48:12 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 4114584499; Fri, 7 Dec 2007 13:48:12 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Bjorn Gronvall References: <1196788555.47558b4bab0ab@imp.free.fr> <1196953310.47580ede28676@imp.free.fr> <20071206175608.594685d9@ibook.sics.se> Date: Fri, 07 Dec 2007 13:48:12 +0100 In-Reply-To: <20071206175608.594685d9@ibook.sics.se> (Bjorn Gronvall's message of "Thu\, 6 Dec 2007 17\:56\:08 +0100") Message-ID: <86hciuu0vn.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: FSCK doesn't correct file size when INCORRECT BLOCK COUNT is found 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: Fri, 07 Dec 2007 12:48:22 -0000 Bjorn Gronvall writes: > Filesystems in general and UFS with soft updates in particular rely on > disks providing accurate response to writes. When write caching is > enabled the disk will lie and tell the operating system that the write > has completed successfully, in reality the data is only cached in disk > RAM. When the power disappears the data will be gone forever. No. This used to be the case with some cheaper disks which ignored the ATA "flush cache" command to score higher on benchmarks, but I doubt you'll find any disks on the market that still do that (at least from reputable manufacturers). ZFS makes extensive use of the "flush cache" command to ensure file system integrity (and in particular to ensure that the intent log is written to disk so it can be replayed in case of a crash). DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no