From owner-freebsd-fs@FreeBSD.ORG Mon Jan 24 15:21:08 2011 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 03EF1106564A for ; Mon, 24 Jan 2011 15:21:08 +0000 (UTC) (envelope-from numisemis@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 87AAB8FC15 for ; Mon, 24 Jan 2011 15:21:07 +0000 (UTC) Received: by ewy24 with SMTP id 24so1931857ewy.13 for ; Mon, 24 Jan 2011 07:21:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=xkRzTgQKEy2bEwFvU4U1UmfB0qNjAZcrDAvsDJyH03Q=; b=MrQ+K3CfrMGnaLJGBA+qPYrhx3iEQijikRw0yzMOkde0wNO5zert+1vEymnwTqnS7f pFv2TFc5QvutNdoSG4ANCeIaqvWquHd6LGYeLKI65EJSgd32L0476bHmlphnq6Wfl4om Egywtr+7e0z2dqjbnAsi8QZDtjdWgHk3zN/2o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=DG1yKfXNKxxNcIYhlKMef5CqEjwjVj+GeW1LRxOwic/HjkePvNKvRUTitjZrAYG6dq iSLO7gLwVFBRPDpiFfGdoQ/Btx+lZ8FjlL3UA9MISfUCVAYuVMeWG30ib/GLx5iLX4MO NVPu7ccOhL9EwLrgiWxVEpxYYLTLyzUYJj/KU= MIME-Version: 1.0 Received: by 10.213.32.18 with SMTP id a18mr4999229ebd.60.1295882114226; Mon, 24 Jan 2011 07:15:14 -0800 (PST) Received: by 10.213.112.141 with HTTP; Mon, 24 Jan 2011 07:15:13 -0800 (PST) In-Reply-To: References: <1ABA88EDF84B6472579216FE@Octa64> <20110122111045.GA59117@icarus.home.lan> <20110124144236.GA19500@icarus.home.lan> Date: Mon, 24 Jan 2011 16:15:13 +0100 Message-ID: From: =?UTF-8?Q?=C5=A0imun_Mikecin?= To: Jeremy Chadwick , freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Write cache, is write cache, is write cache? 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: Mon, 24 Jan 2011 15:21:08 -0000 2011/1/24 =C5=A0imun Mikecin > 2011/1/24 Jeremy Chadwick > >> The term "flush" means many different things. fsync(2), for example, >> behaves differently on UFS than it does on ZFS. People think that >> "flush" means "guarantee the data written was written to disk", but >> ensuring an actual ATA/SCSI command completes **and** has had its data >> written to the platters is an entirely different beast (IMO) than "flush >> kernel buffers to disk and hope for the best". >> > > AFAIK, BIO_FLUSH should complete when data was written to disk (not > before), or in the case of battery backed cache: when data was written to > battery backed cache. > AFAIK, ZFS doesn't only "flush kernel buffers" (like UFS does), but also > executes BIO_FLUSH every X seconds (X=3D5 if my memory serves me well). S= o, > you shouldn't loose data that was written before BIO_FLUSH executed. > > With single disks, all I've seen are read/write errors which can't be > >> repaired. "zpool status" will actually show what files got affected as >> a result of the issue, though sometimes "zpool scrub" needs to be run >> before this can be detected. > > > Adding redudancy does make your data safer, but if everything is working = as > explained, sudden power-loss shouldn't be the cause of those errors even > with single disks. Correct me if you think that I'm mistaken. > Well, when I think more about it, those errors might be from writing to dis= k after last call to BIO_FLUSH. So you loose last 5 seconds at most. Not something worth writing home about considering the performance advantage yo= u get by enabling write cache.