From owner-freebsd-fs@FreeBSD.ORG Fri Feb 15 16:14:24 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 9E336EB7 for ; Fri, 15 Feb 2013 16:14:24 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.7]) by mx1.freebsd.org (Postfix) with ESMTP id 354D670F for ; Fri, 15 Feb 2013 16:14:24 +0000 (UTC) Received: from [78.35.132.100] (helo=fabiankeil.de) by smtprelay03.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1U6NvU-0005MD-F4; Fri, 15 Feb 2013 17:14:16 +0100 Date: Fri, 15 Feb 2013 17:11:44 +0100 From: Fabian Keil To: grarpamp Subject: Re: Crazy ZFS ZIL options: md(4) umass(4) Message-ID: <20130215171144.710bf9af@fabiankeil.de> In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/6VHHzP9S0I0LKlYpaDRux_r"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: freebsd-fs@freebsd.org 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 16:14:24 -0000 --Sig_/6VHHzP9S0I0LKlYpaDRux_r Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable grarpamp wrote: > > ZIL is there for you to recover transactions in case of a crash. > > It is your safety net. >=20 > I always thought the ZIL was pushed out safely. So that still > no matter what the disk would be consist [1]. Like when crash > you just lose the ZIL's since the last ZIL push. Which odds > are will be just work product here. I'd expect the pool to remain consistent as long as one of the uberblocks "works", of course you'd still lose the transactions that haven't made it to the disk yet. I agree that using RAM that isn't battery-backed for the ZIL doesn't make much sense, though, and that disabling sync is more reasonable if you can live with losing transactions. > > Use the RAM for ARC, it will provide more performance. >=20 > But about reducing fragmentation without separate ZIL. > I'm admittedly over full and will need to move data to > new pool anyway. Just that with ZIL in main pool what article > I read says problem can mostly come back without separate zil. > I tend to run full till annoyed to redesign, bad habit. Disabling sync potentially reduces the fragmentation and you could additionally increase vfs.zfs.txg.synctime_ms and vfs.zfs.txg.timeout which (again potentially) reduce fragmentation further but can negatively impact "interactivity". I'm not aware of a quick way to measure fragmentation on ZFS pools, though, so I'd be interested to know how you intend to confirm that your "fragmentation tuning" actually improves things. =20 > > USB ... unreliable >=20 > I would have to test USB bus and devs for stablility. But > I do have local lifetime warranty on 32GiB devices :) > So maybe mirror 2 of them, or 2x2. > Due to crypto I only get 7-15MiB/s on spindle anyway. I'm sure a slow ZIL could throttle this even further. Fabian --Sig_/6VHHzP9S0I0LKlYpaDRux_r Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEeXkYACgkQBYqIVf93VJ2gZgCfSm0J4VqzjXB2lSp+HmDEkHr9 EWgAnAkgOc98uzyGcwkofROkugw8YKCg =YV93 -----END PGP SIGNATURE----- --Sig_/6VHHzP9S0I0LKlYpaDRux_r--