From owner-freebsd-fs@FreeBSD.ORG Fri Mar 28 21:52:20 2014 Return-Path: Delivered-To: freebsd-fs@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 ESMTPS id D7EB1F7F for ; Fri, 28 Mar 2014 21:52:20 +0000 (UTC) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 56572A2B for ; Fri, 28 Mar 2014 21:52:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id s2SLqHCt048309; Sat, 29 Mar 2014 01:52:17 +0400 (MSK) (envelope-from marck@rinet.ru) Date: Sat, 29 Mar 2014 01:52:17 +0400 (MSK) From: Dmitry Morozovsky To: Freddie Cash Subject: Re: zfs l2arc warmup In-Reply-To: Message-ID: References: <20140328005911.GA30665@neutralgood.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Sat, 29 Mar 2014 01:52:17 +0400 (MSK) Cc: "freebsd-fs@freebsd.org" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 21:52:21 -0000 On Fri, 28 Mar 2014, Freddie Cash wrote: > > I'm thinking not about losing the transaction, but possibly putting your > > filesystem in the middle of (database PoV) transaction, hence render your > > DB > > inconsistent? > > > > Quick googling seems to be uncertain about it... > > > > ?That I don't know. Again, I'm not a ZFS code guru; just a very > happy/active ZFS user and reader of stuff online. :) > > You're thinking of the small window where: > - database writes transaction to disk > - zfs writes ?the data to the ZIL on the log vdev > - zfs returns "data is written to disk" to the DB > - zfs queues up the write to the pool > - the log device dies > - the pool is forcibly exported/server loses power Pretty much the same I'm just written in the parallel reply ;) > Such that the DB considers the transaction complete and the data safely > written to disk, but it's actually only written to the ZIL on the separate > log device (which no longer exists) and is not stored in the pool yet. So, if ZIL dies but server is alive the sync write will be done, IIUC from your and other's comments? Then, of course, it will shorten the width of dangerous to nearly zero. > Yeah, that could be a problem. A very unlikely event, although not > entirely impossible. > > ?I would think it would be up to the database to be able to roll-back a > database to prior to the corrupted transaction. If the DB has a log or > journal or whatever, then it could be used to roll-back, no? If it could detect this situation, yes. I'm not sure detecting this while getting (previously) state like "write has been done" couldbe simple though ;P > It's still considered best practice to use mirror log device. It's just no > longer required, nor does a dead log lead to a completely dead pool.? Well, I suppose the middle point is like "weight your abilities to lose data, and prepare measures" ;P For the database case, I'm not so sure, alas. But, anyway, thank you very much for thougthful comments! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------