From owner-freebsd-fs@FreeBSD.ORG Tue Oct 14 08:25:12 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D9B1EEF4; Tue, 14 Oct 2014 08:25:12 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 923FC9EE; Tue, 14 Oct 2014 08:25:12 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id DA42B20E70936; Tue, 14 Oct 2014 08:25:11 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.2 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,RDNS_DYNAMIC,STOX_REPLY_TYPE autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id 834ED20E70934; Tue, 14 Oct 2014 08:25:10 +0000 (UTC) Message-ID: From: "Steven Hartland" To: "K. Macy" , "Mark Martinec" References: <54372173.1010100@ijs.si> <644FA8299BF848E599B82D2C2C298EA7@multiplay.co.uk> <54372EBA.1000908@ijs.si> <543731F3.8090701@ijs.si> <543AE740.7000808@ijs.si> <6E01BBEDA9984CCDA14F290D26A8E14D@multiplay.co.uk> <14ADE02801754E028D9A0EAB4A16527E@multiplay.co.uk> <543C3C47.4010208@ijs.si> <543C7B43.5020301@ijs.si> Subject: Re: zpool import hangs when out of space - Was: zfs pool import hangs on [tx->tx_sync_done_cv] Date: Tue, 14 Oct 2014 09:25:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: "freebsd-fs@FreeBSD.org" , FreeBSD Stable X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 08:25:13 -0000 ----- Original Message ----- From: "K. Macy" > On Mon, Oct 13, 2014 at 6:24 PM, Mark Martinec > wrote: >> On 10/14/2014 03:15, K. Macy wrote: >>> >>> What is using the extra space in the pool? Is there an unmounted >>> dataset or snapshot? Do you know how to easily tell? Unlike txg and >>> zio processing I don't have the luxury of having just read that part >>> of the codebase. >> >> >> Most likely the snapshots (regular periodic snapshots). >> Changes after upgrading an OS can maybe take an additional 50% >> of space (just guessing). Btw, ashift=12. >> Still can't see how that would amount to 4 GiB, but it's possible. >> > > Disconcerting. Is this something that others are likely to hit? Should > accounting for writes fail with ENOSPC a bit earlier so that we never > reach a state like this? I.e. non-metadata writes will fail at a lower > threshold than data or if that is already the case, reduce the > threshold further. I thought I remembered seeing some recent changes in this area, but I can't find them ATM. Something to raise on the openzfs list. Regards Steve