From owner-freebsd-fs@FreeBSD.ORG Fri Mar 28 21:45:11 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E88EE1D for ; Fri, 28 Mar 2014 21:45:11 +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 EE89197E for ; Fri, 28 Mar 2014 21:45:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id s2SLj8GJ048212; Sat, 29 Mar 2014 01:45:08 +0400 (MSK) (envelope-from marck@rinet.ru) Date: Sat, 29 Mar 2014 01:45:08 +0400 (MSK) From: Dmitry Morozovsky To: mikej Subject: Re: zfs l2arc warmup In-Reply-To: <33ff828c517307c9681c361a12cff2ee@mail.mikej.com> Message-ID: References: <20140328005911.GA30665@neutralgood.org> <33ff828c517307c9681c361a12cff2ee@mail.mikej.com> 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:45:08 +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:45:11 -0000 On Fri, 28 Mar 2014, mikej wrote: > > [snip most again] > > > > > Around ZFSv14-ish, the ability to import a pool with a missing ZIL was > > > added. > > > > > > Remember the flow of data in ZFS: > > > async write request --> TXG --> disk > > > sync write request --> ZIL > > > \--> TXG --> disk > > > > > > All sync writes are written to the pool as part of a normal async TXG > > > after > > > its written sync to the ZIL. And the ZIL is only ever read during pool > > > import. > > > > On the other side, doesn't it put the risk on sync-dependent, like database, > > systems? > > > > 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... > > As I understand it..... (And I am always looking for an education) > > Any files system that honors fsync and provided the DB uses fsync should be > fine. > > Any data loss then will only be determined by what transaction (log) > capabilities the DB has. And? 1. The DB issues "sync WAL" request, which is translated to fsync-like FS requests, there are (IIUC) should ne directed to ZIL. 2. ZIL is failing in the middle of the request, or, even more bad, after reporting that ZIL transaction is done, but before translating ZIL to the underlying media 3. inconsistend DB? I'm in hope I'm wrong somewhere... -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------