From owner-freebsd-fs@FreeBSD.ORG Thu May 12 09:05:51 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 50CF7106566C for ; Thu, 12 May 2011 09:05:51 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id 34FF38FC0A for ; Thu, 12 May 2011 09:05:50 +0000 (UTC) Received: from omta01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by qmta05.emeryville.ca.mail.comcast.net with comcast id iZ5q1g0040EPchoA5Z5qF5; Thu, 12 May 2011 09:05:50 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta01.emeryville.ca.mail.comcast.net with comcast id iZ5Q1g00W1t3BNj8MZ5WCz; Thu, 12 May 2011 09:05:45 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 74C9E102C19; Thu, 12 May 2011 02:05:24 -0700 (PDT) Date: Thu, 12 May 2011 02:05:24 -0700 From: Jeremy Chadwick To: ?imun Mikecin Message-ID: <20110512090524.GA2106@icarus.home.lan> References: <4DCA5620.1030203@dannysplace.net> <4DCB455C.4020805@dannysplace.net> <20110512033626.GA52047@icarus.home.lan> <4DCB7F22.4060008@digsys.bg> <20110512083429.GA58841@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs Subject: Re: ZFS: How to enable cache and logs. 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: Thu, 12 May 2011 09:05:51 -0000 On Thu, May 12, 2011 at 10:45:01AM +0200, ?imun Mikecin wrote: > On 12. svi. 2011., at 10:34, Jeremy Chadwick wrote: > > > > I had no idea the primary point of a SLOG was to deal with applications > > that make use of O_SYNC. I thought it was supposed to improve write > > performance for both asynchronous and synchronous writes. Obviously I'm > > wrong here. > > If the application is not using O_SYNC, write operation returns to the > app before the data is actually written. Yes, I understand that -- O_SYNC is effectively the same as issuing fsync(2) after every write(2) call. I just thought that the ZIL improved both synchronous and asynchronous writes, but my understanding of the ZIL is obviously very limited. > > What guarantee is there that the intent log -- which is written to the > > disk -- actually got written to the disk in the middle of a power > > failure? There's a lot of focus there on the idea that "the intent log > > will fix everything, but may lose writes", but what guarantee do I have > > that the intent log isn't corrupt or botched during a power failure? > > I expect that checksumming also works for ZIL (anybody knows?). If > that is the case, corruption would be detected, but you will have lost > data unless you are using mirrored slog devices. I can't believe that statement either (the last line). I guess that's also what I'm asking here -- what guarantee do you have that even with a mirrored 2-disk SLOG (or heck, 3 or 4!) that *no data* will be *lost* during a power outage? It seems to me the proper phrase would be "the likelihood of losing an entire pool during a power outage is lessened". Alexander indirectly hinted at this in another post of his tonight, specifically regarding zpool v15 versus v28: "The difference between v15 and v28 is the amount of data you lose (the entire pool vs. only what is still on the log devices)". This makes much more sense to me. It seems that in a power outage, there will always be some form of data loss. I imagine even systems that have hardware RAM/cache with BBUs on everything; there's always some form of caching going on *somewhere* within a system, from CPU all the way up, that guarantees some degree of data loss). I guess I'm OCD'ing over the terminology here. Sorry. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB |