From owner-freebsd-fs@FreeBSD.ORG Fri Mar 28 21:01:29 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 A8F7EB22 for ; Fri, 28 Mar 2014 21:01:29 +0000 (UTC) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6C6B2259 for ; Fri, 28 Mar 2014 21:01:29 +0000 (UTC) Received: by mail-ob0-f174.google.com with SMTP id wo20so6527120obc.19 for ; Fri, 28 Mar 2014 14:01:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XAzsxm+/6OUxu4QXtzNpnQnx/HHAEMLSvJ5gl2IQ+N4=; b=hAY8t+Mj2hglnzL+J1piOR6q5gJM820bh/rmpkMqo2b2WhL98tQcCUJOd+5Eev2CH5 Aoz6AE4wrq/xDVEkUIWa09PE5DjqP1CVDVgBykA60xocRL6RU8s0dTm1TPq+YeOyBJqC OG5/Tk4Ys1c3mvgiSVypAg8+f1GKu4iIGhJxTYK80HNGryP37tHzV+XePKM57eBFeumJ HWsgibIaIzC3Gjwl5Pq8IpEz/IGdVb9AZY3H7mQi8FxsvnRSGDJH7iPTJ0KtWgm72uN5 d5wUPLolYMf/h+fC84Ick7ikWA4w80QkNTmVElFBXMn6FMd32f4+U6DpDeeHfEKQXb+p fhAA== MIME-Version: 1.0 X-Received: by 10.182.43.161 with SMTP id x1mr8393740obl.5.1396040488769; Fri, 28 Mar 2014 14:01:28 -0700 (PDT) Received: by 10.76.180.40 with HTTP; Fri, 28 Mar 2014 14:01:28 -0700 (PDT) In-Reply-To: References: <20140328005911.GA30665@neutralgood.org> Date: Fri, 28 Mar 2014 14:01:28 -0700 Message-ID: Subject: Re: zfs l2arc warmup From: Freddie Cash To: Dmitry Morozovsky Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 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:01:29 -0000 On Fri, Mar 28, 2014 at 2:00 PM, Freddie Cash wrote: > On Fri, Mar 28, 2014 at 1:40 PM, Dmitry Morozovsky wrote= : > >> On Fri, 28 Mar 2014, Joar Jegleim wrote: >> >> [snip most of] >> >> > > Have you measured to see if, or do you otherwise know for sure, that >> you >> > > really do need a ZIL? I suggest not adding a ZIL unless you are >> certain >> > > you need it. >> > Yes, I only recently realized that too, and I'm really not sure if a >> > zil is required. >> > Some small portion of files (som hundre MB's) are served over nfs from >> > the same server, if I understand it right a zil will help for nfs >> > stuff (?) , but I'm not sure if it's any gain of having a zil today. >> > On the other hand, a zil doesn't have to be big, I can simply buy a >> > 128GB ssd which are cheap today . >> >> Please don't forget that, unlike L2ARC, if you lost ZIL during sync writ= e, >> you're effectively lost the pool. >> > > =E2=80=8BNope. Not even close. > > The ZIL is only ever read at boot time. If you lose the ZIL between the > time the data is written to the ZIL and the time the async write of the > data is actually done to the pool ... and the server is rebooted at that > time, then you get an error message at pool import. > > You can then force the import of the pool, losing any *data* in the ZIL, > but nothing else. > > It used to be (back in the pre-ZFSv=E2=80=8B13-ish days) that if you lost= the ZIL > while there was data in it that wasn't yet written to the pool, the pool > would fault and be gone. Hence the rule-of-thumb to always mirror the ZI= L. > > 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. > > =E2=80=8B[Note, I'm not a ZFS developer so some of the above may not be 1= 00% > accurate, but the gist of it is.]=E2=80=8B > > =E2=80=8BOh, and if you lose the separate log vdev during normal operation,= then the pool reverts to using the ZIL inside of the pool. IOW, there's always a ZIL in a pool, whether that be internal to the pool or as part of a separate log vdev. --=20 Freddie Cash fjwcash@gmail.com