From owner-freebsd-fs@FreeBSD.ORG Fri Feb 15 09:34:52 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 92F45B12 for ; Fri, 15 Feb 2013 09:34:52 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.freebsd.org (Postfix) with ESMTP id 2FB1FD24 for ; Fri, 15 Feb 2013 09:34:51 +0000 (UTC) Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0MMcRu-1Ty4Db13PC-008FbS; Fri, 15 Feb 2013 10:34:45 +0100 Message-ID: <511E0133.9010600@brockmann-consult.de> Date: Fri, 15 Feb 2013 10:34:43 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: Crazy ZFS ZIL options: md(4) umass(4) References: <43BC680B-4FC6-4CDB-A590-12ACC78959B7@digsys.bg> In-Reply-To: <43BC680B-4FC6-4CDB-A590-12ACC78959B7@digsys.bg> X-Enigmail-Version: 1.5 X-Provags-ID: V02:K0:Darbq9wIRF2yVwnlHvQ144peS5k8f5LOOojlVMyEihp Gw5cjMAKxbbRKHWcAt5DFlgGmUe8RWHfLhvezIVCAPU7tsfjb8 dDbHXgMSJ3HuQM5D/04q2BSPJkDw6qSfv8v99bXGVbhB7tAHa6 RtHQuBfdDiNBSnBv1/u793AguljJ/RsnyIpxyiwEmW6x0+5/XN +gJttIYrKT/UFqbLCQhuRrv0fyCpNF9ZB6Rgie+6O70GSAFxla jy4RrzVWGx6+eY16wgdZP/MZGg6m9Vr/wUPJpbl3amQ9ZEpFUA B/MkTamntenwpWDitR3EhQR8EXMC6UGQ0q7QoL/Mtnk9+Tckp5 TfomnhLFP2qfCt8bMOhA3cBrPZxZL9wzPYoHRW9a7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 09:34:52 -0000 On 2013-02-15 10:10, Daniel Kalchev wrote: > In short, don't. > > ZIL is not a cache. ZIL is there for you to recover transactions in case of a crash. It is your safety net. > If you don't have low latency SSD, put it on separate spinning disk, but by all means never on RAM and USB only as a last resort, because USB is slow for most uses and it is also extremely unreliable. > > Use the RAM for ARC, it will provide more performance. > > Daniel I second that. It may even harm you because some transactions are on the RAM zil and will have to be rolled back to get the pool online, using options like: -F Recovery mode for a non-importable pool. Attempt to return the pool to an importable state by *discarding the last few** ** transactions*. Not all damaged pools can be recovered by using this option. If successful, the data from the discarded transactions is irretrievably lost. This option is ignored if the pool is importable or already imported. If you lose power on the RAM, your ram ZIL is useless (it was only written, never read... just wasted memory). ZIL is only read for recovering from an interruption. Think of it like this... random writes come from an app, get written sequentially on the ZIL (fast on disk since it's written sequentially but fragmented since it's actually random writes) and also saved in RAM. Then as the system has time, the changes are saved on disk from RAM, so it's like a slightly slow non-volatile RAM cache. If the system crashes, the RAM is lost (so is your RAM ZIL), but the fragmented ZIL slog (sequential log) is safe, and used to recover what was lost from RAM. I've crashed my FreeBSD boxes (with faulty ZIL disk firmware) and the ZIL shows checksum errors when it starts, and self-heals from the mirror; it must have some data integrity just like the pool. I don't know the details. > > On Feb 15, 2013, at 10:00 AM, grarpamp wrote: > >> I have thousands of small files being written most under 8KiB, they >> either end up being removed or combined in various ways to >> produce a set of data that is stored long term. I also have >> tens of 10-50MiB files similarly, but rarely. It's not fully clear >> to me the benefits of a split ZIL. Some say a split ZIL will ward >> off some fragmentation, which pushing over 80% I'm sure to see >> otherwise. Plus a speed boost if on faster media. And maybe >> even no need to commit some ZIL to disk as small files are >> removed before ZFS decides to aggregate? >> >> Anyway, use case aside, I can put 1GiB of ram as ZIL.Same for 32GiB USB. >> RAM is obviously fast and power fail prone. >> USB is slow and power safe. >> Either could be mirrored, 2xRAM, 2xUSB. >> >> - If I lose power on RAM, will the disk still be consistent? >> - What data integrity does ZIL have? None? ZFS dataset's sha256? >> - Any production experiences with this crazy ideas? >> >> Thx. >> _______________________________________________ >> freebsd-fs@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-fs >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.maloney@brockmann-consult.de Internet: http://www.brockmann-consult.de --------------------------------------------