From owner-freebsd-fs@FreeBSD.ORG Tue Jan 12 08:20:46 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D485D1065670 for ; Tue, 12 Jan 2010 08:20:46 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 5F9528FC21 for ; Tue, 12 Jan 2010 08:20:45 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o0C8KhFk018547; Tue, 12 Jan 2010 09:20:44 +0100 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 27F4824; Tue, 12 Jan 2010 09:20:43 +0100 (CET) Date: Tue, 12 Jan 2010 09:20:43 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: kmacy@freebsd.org Message-Id: <20100112092043.d1370d55.gerrit@pmp.uni-hannover.de> In-Reply-To: <82c4140e1001111529u7d7ac409h63dda4cc10b76522@mail.gmail.com> References: <20100110161206.GA86684@plebeian.afflictions.org> <20100110184612.GC86684@plebeian.afflictions.org> <82c4140e1001111529u7d7ac409h63dda4cc10b76522@mail.gmail.com> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.4; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.12.80923 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS on top of GELI X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 08:20:46 -0000 On Mon, 11 Jan 2010 15:29:54 -0800 "K. Macy" wrote about Re: ZFS on top of GELI: KM> > That is true, but using a single device for a dedicated ZIL is a huge KM> > no-no, considering it's an intent log, it's used to reconstruct the KM> > pool in case of a power failure for example, should such an event KM> > occur at the same time as a ZIL provider dies, you lose the entire KM> > pool because there is no way to recover it, so if ZIL gets put KM> > "elsewhere", that elsewhere really should be a mirror and sadly I KM> > don't see myself affording to use 2 SSDs for my setup :) KM> This is false. The ZIL is used for journalling synchronous writes. If KM> your ZIL is lost you will lose the data that was written to the ZIL, KM> but not yet written to the file system proper. Barring disk KM> corruption, the file system is always consistent. So how would ZFS behave if ZIL is sitting on a single disk that is then lost? Throw away the intented writes and continue happily from there on? I still have some broken volume sitting around that panics the kernel when trying to replay the (obviously somehow corrupted) ZIL (see ) and I wonder if situations like this could be handled by taking out the ZIL drive (only if there is a dedicated one, of course). cu Gerrit