From owner-freebsd-stable@FreeBSD.ORG Thu Oct 16 07:55:25 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CCA2E469; Thu, 16 Oct 2014 07:55:25 +0000 (UTC) Received: from odin.blazingdot.com (odin.blazingdot.com [204.109.60.170]) by mx1.freebsd.org (Postfix) with ESMTP id A9FC88B0; Thu, 16 Oct 2014 07:55:25 +0000 (UTC) Received: by odin.blazingdot.com (Postfix, from userid 1001) id 124AB130C8F; Thu, 16 Oct 2014 03:55:19 -0400 (EDT) Date: Thu, 16 Oct 2014 03:55:19 -0400 From: Marcus Reid To: Steven Hartland Subject: Re: zpool import hangs when out of space - Was: zfs pool import hangs on [tx->tx_sync_done_cv] Message-ID: <20141016075518.GA14459@blazingdot.com> References: <14ADE02801754E028D9A0EAB4A16527E@multiplay.co.uk> <543C3C47.4010208@ijs.si> <138CF459AA0B41EB8CB4E11B3DE932CF@multiplay.co.uk> <543D0953.1070604@ijs.si> <8F4036C658724468B34B20CCBA658E43@multiplay.co.uk> <520ED11771DE40FBAEFCC066D2FF0441@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <520ED11771DE40FBAEFCC066D2FF0441@multiplay.co.uk> X-Coffee-Level: nearly-fatal User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Mark Martinec , freebsd-fs@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 07:55:25 -0000 On Thu, Oct 16, 2014 at 03:56:23AM +0100, Steven Hartland wrote: > Fix for this has now been committed: > https://svnweb.freebsd.org/changeset/base/273158 > > I'm already talking with re@ to get this in to the 10.1 release. Thank you for that. I looked at your thread on the illumos zfs list, and from what I gather, if you aren't wedged into a state where you have to import read-only, you don't have to worry about leaked data in your pool, correct? I always have a small number of 'deferred free' blocks that's always somewhere between 8 and 10: 9 108K 15.5K 108K 12.0K 6.97 0.00 deferred free Also, if you run 'zdb -bb ' on a live pool, you can get a bunch of: leaked space: vdev 0, offset 0x16464c2000, size 1048576 ... and then: block traversal size 14586265600 != alloc 14667571200 (leaked 81305600) which I believe is normal and unrelated. Marcus