From owner-freebsd-questions@FreeBSD.ORG Mon Oct 14 17:54:16 2013 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E22BE8D3 for ; Mon, 14 Oct 2013 17:54:15 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [93.89.92.64]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9EDBD2AE7 for ; Mon, 14 Oct 2013 17:54:15 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id DB80AE6DDC; Mon, 14 Oct 2013 18:54:06 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mail; bh=LIXjF6abSgxh Hah92PpxkJ5zGb8=; b=wM3EnqLeKCL7sjJdkqJvyJSPaUK1PXPMZv8lizFADck/ /OMQZM73ht6OuQ7HFpuIPy0gKFIQAvRUfH9kUqV7qWmT5wsRv0pr5G1hxAgSA8vq IuYPL6WesFmBueu55qSPe617LsQ7gz7bZoH+mHau8mFhc90ITobYfHpXaOwARVA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mail; b=RwYBFB 7ykbtNu1eRdZY3wLLien+tY/gHXMbX+J+dGBqNMd9H8L/m84ud1jMjD6MTkUAgTt y+SQVaZrHZf5ntGUtAZC9DT7P4RuadiG8JhPaWALbpAb/3t+7ZMB4ikkH/qPQUOb VjXDXpRv9fDfH8ULm725G+akXXsdsvEjT/bwk= Received: from [192.168.2.103] (unknown [93.89.81.205]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id A71F0E6DD6; Mon, 14 Oct 2013 18:54:05 +0100 (BST) Message-ID: <525C2FBC.4080808@cran.org.uk> Date: Mon, 14 Oct 2013 18:54:04 +0100 From: Bruce Cran User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: CeDeROM , Brad Mettee Subject: Re: SU+J Lost files after a power failure References: <525A6831.5070402@gmail.com> <20131014133953.58f74659@gumby.homeunix.com> <525C1D1C.9050708@gmail.com> <525C2554.7080203@pchotshots.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: David Demelier , Adam Vande More , FreeBSD Questions X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 17:54:16 -0000 On 10/14/2013 6:16 PM, CeDeROM wrote: > Isn't there Journal to prevent and reverse such damage? Unlike other journaling filesystems, UFS+J only protects the metadata, not the data itself - i.e. I think it ensures you won't have to run a manual fsck, but just like plain old UFS files may be truncated as the journal is replayed. For ext3, https://www.kernel.org/doc/Documentation/filesystems/ext3.txt explains the different modes, with 'ordered' being default: Data Mode --------- There are 3 different data modes: * writeback mode In data=writeback mode, ext3 does not journal data at all. This mode provides a similar level of journaling as that of XFS, JFS, and ReiserFS in its default mode - metadata journaling. A crash+recovery can cause incorrect data to appear in files which were written shortly before the crash. This mode will typically provide the best ext3 performance. * ordered mode In data=ordered mode, ext3 only officially journals metadata, but it logically groups metadata and data blocks into a single unit called a transaction. When it's time to write the new metadata out to disk, the associated data blocks are written first. In general, this mode performs slightly slower than writeback but significantly faster than journal mode. * journal mode data=journal mode provides full data and metadata journaling. All new data is written to the journal first, and then to its final location. In the event of a crash, the journal can be replayed, bringing both data and metadata into a consistent state. This mode is the slowest except when data needs to be read from and written to disk at the same time where it outperforms all other modes. -- Bruce Cran