From owner-freebsd-fs@FreeBSD.ORG Sun Dec 9 02:13:08 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 8E9D116A419 for ; Sun, 9 Dec 2007 02:13:08 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (adsl-75-1-14-242.dsl.scrm01.sbcglobal.net [75.1.14.242]) by mx1.freebsd.org (Postfix) with ESMTP id 6BF1513C457 for ; Sun, 9 Dec 2007 02:13:08 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id lB92CsQ6070139; Sat, 8 Dec 2007 18:12:58 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200712090212.lB92CsQ6070139@gw.catspoiler.org> Date: Sat, 8 Dec 2007 18:12:54 -0800 (PST) From: Don Lewis To: julien.bellang@free.fr In-Reply-To: <47595C8C.6060203@free.fr> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-fs@FreeBSD.org, des@des.no, rees@FreeBSD.org Subject: Re: FSCK failed does'nt 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: Sun, 09 Dec 2007 02:13:08 -0000 On 7 Dec, julien wrote: > I can't get a UPS in my environment. Would it be possible to use a laptop for this application? > I already tested with the write cache desactivated, but the problem > still the same, I obtain files with holes and incorrect size and > blockcount. The only difference is that there is less holes and > performance are falling down. > > The problem is really easy to reproduce, you have just to copy several > big files and shutdown the power in the midle of the copy. The disk writes for sequential blocks of the file that are generated by the copy command are probably getting re-ordered by the disk driver in order to optimize the I/O ordering. Interrupting this out of order sequence with a power failure will result in the holey files that you are seeing. With FreeBSD 6.x and earlier, about the only thing you can do in this situation is to use the "sync" mount option in addition to disabling write caching, which will force each of the writes done by the file copy to actually copy the data to disk in sequential order. Unfortunately, this will reduce write performance even more. If you use the "sync" mount option without write caching, I suspect that the files won't look holey to fsck, but some of the blocks of the files being written at the time of power failure will contain parts of previously deleted files and other random garbage. This could be a security issue if userA's new file could contain some of userB's old data. If you were running FreeBSD 7.0, then gjournal+ufs or zfs could be possible solutions to your problem. I haven't tried either, so I can't comment on how well they might work.