From owner-freebsd-stable@FreeBSD.ORG Tue Jan 12 04:00:45 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2EE01065670; Tue, 12 Jan 2010 04:00:45 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f177.google.com (mail-iw0-f177.google.com [209.85.223.177]) by mx1.freebsd.org (Postfix) with ESMTP id 5D5428FC15; Tue, 12 Jan 2010 04:00:45 +0000 (UTC) Received: by iwn7 with SMTP id 7so6899522iwn.7 for ; Mon, 11 Jan 2010 20:00:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:cc:subject :in-reply-to:message-id:references:user-agent:x-openpgp-key-id :x-openpgp-key-fingerprint:mime-version:content-type; bh=MVi9V8OJjrPEwHVfDl2wE1SqMX9NCS9FyZaQPvMrIyw=; b=GmuSqU9TH4IZhgkRAI5DdwDcH3oAYGzc60a9AVN1Dm0EH7YuU2RwdkVwVpQvk0iBjJ /Si4OlZb4gN0Dk4IyQenIFPqcbMw7A9aip21iOEXiAS8uvn8n+izsYm4PyP0QLaGfrqM kBq+QfpStdkoXl6pWz07kPx4rpxPoZulnAyQQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=WfoFkPbHl9YdcOE+eo3CrZ+uqm7xld5SUZRNUSowko+iloE5HZ4Ffk39JrD/Y2dXXe rELl/sn3DKzir54bBl8i/F0H3tTLbyRw4js2MMZgGT+pysfGKyNDYPAR07QwbGQYAfaK tpR8Qe8vOT7GdTdwnpq2oC6haHbOrqOvv6Hx4= Received: by 10.231.162.83 with SMTP id u19mr44733ibx.25.1263268839837; Mon, 11 Jan 2010 20:00:39 -0800 (PST) Received: from centel.dataix.local (ppp-21.49.dialinfree.com [209.172.21.49]) by mx.google.com with ESMTPS id 22sm2879656iwn.4.2010.01.11.20.00.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 Jan 2010 20:00:38 -0800 (PST) Sender: "J. Hellenthal" Date: Mon, 11 Jan 2010 23:00:09 -0500 From: jhell In-Reply-To: Message-ID: References: <20100110161206.GA86684@plebeian.afflictions.org> <20100110184612.GC86684@plebeian.afflictions.org> <82c4140e1001111529u7d7ac409h63dda4cc10b76522@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org, FreeBSD-STABLE Mailing List Subject: Re: ZFS on top of GELI X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 04:00:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 11 Jan 2010 19:45, fjwcash@ wrote: > On Mon, Jan 11, 2010 at 4:24 PM, Dan Naumov wrote: > >> On Tue, Jan 12, 2010 at 1:29 AM, K. Macy wrote: >>>>> >>>>> If performance is an issue, you may want to consider carving off a >> partition >>>>> on that SSD, geli-fying it, and using it as a ZIL device. You'll >> probably >>>>> see a marked performance improvement with such a setup. >>>> >>>> That is true, but using a single device for a dedicated ZIL is a huge >>>> no-no, considering it's an intent log, it's used to reconstruct the >>>> pool in case of a power failure for example, should such an event >>>> occur at the same time as a ZIL provider dies, you lose the entire >>>> pool because there is no way to recover it, so if ZIL gets put >>>> "elsewhere", that elsewhere really should be a mirror and sadly I >>>> don't see myself affording to use 2 SSDs for my setup :) >>>> >>> >>> This is false. The ZIL is used for journalling synchronous writes. If >>> your ZIL is lost you will lose the data that was written to the ZIL, >>> but not yet written to the file system proper. Barring disk >>> corruption, the file system is always consistent. >>> >>> -Kip >> >> Ok, lets assume we have a dedicated ZIL on a single non-redundant >> disk. This disk dies. How do you remove the dedicated ZIL from the >> pool or replace it with a new one? Solaris ZFS documentation indicates >> that this is possible for dedicated L2ARC - you can remove a dedicated >> l2arc from a pool at any time you wish and should some IO fail on the >> l2arc, the system will gracefully continue to run, reverting said IO >> to be processed by the actual default built-in ZIL on the disks of the >> pool. However the capability to remove dedicated ZIL or gracefully >> handle the death of a non-redundant dedicated ZIL vdev does not >> currently exist in Solaris/OpenSolaris at all. >> >> That has been implemented in OpenSolaris, do a search for "slog removal". > It's in a much newer zpool version than 13, though. > > What I have seen more often by users is taking the usage of slog/ZIL wrong. For instance dedicating a whole SSD or another HDD as the slog. Your slog/ZIL only has to be big enough to handle 10 seconds of synchronous writes before it flushes. A recommended ZIL from Sun Micro is 128MB but you may not even see that fully used for general purpose cases. I had is to dedicate a partition on the same disk that the pool is on and adding another ZIL vdev from another disk in the system. Results of this imply that if the off-disk ZIL dies for some stupid reason it falls back to the one that rests on the same disk as the pool and allows to replace the off-disk ZIL with something else. PS: Save your disk space and use 256MB thumb drives. you can easily get 16 of those at your local Walmart and have a priceless light show for a romantic dinner with the wife. :) - -- Mon Jan 11 22:31:17 2010 jhell -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLS/PZAAoJEJBXh4mJ2FR+CTUH/RIqmRPE8SdKZYY7WIC/K9Yk HThaiYHs6a15ZY58q2nHG0x5J85TOBMN4yvC1rI1DGcjX9SXlyjxY+jJ0sdIAbHz N2+nT95X3SbNCPXtA3qo6uTplIiZnu9xgcAnFmjBh96Aq7qzcIvtFe2QMuxTp/lI Na8K4t7udDFQ9xIoyptk/PukKvV/EtzDx449w6VPxu0fkXK812uWWl+jFy3XchrW QfExuNIhVadcnxOB5/BQaAyd6daaI9tZNyARo43ww7bEKxaFP2Awre/IYfeuKZtm /n4TOdOoookyIIO0fMWDQ4WyLLsQD6eHug0B0Ef7LYcrUkPEYFJQVxujhx/cyhI= =cjuO -----END PGP SIGNATURE-----