From owner-freebsd-bugs@FreeBSD.ORG Sun Aug 18 15:40:03 2013 Return-Path: Delivered-To: freebsd-bugs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A9CE5C4B for ; Sun, 18 Aug 2013 15:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 89A502D0C for ; Sun, 18 Aug 2013 15:40:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r7IFe30c051668 for ; Sun, 18 Aug 2013 15:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r7IFe3ll051667; Sun, 18 Aug 2013 15:40:03 GMT (envelope-from gnats) Resent-Date: Sun, 18 Aug 2013 15:40:03 GMT Resent-Message-Id: <201308181540.r7IFe3ll051667@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Christopher Harrison Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0B2179FA for ; Sun, 18 Aug 2013 15:33:47 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from oldred.freebsd.org (oldred.freebsd.org [8.8.178.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EC5682CB8 for ; Sun, 18 Aug 2013 15:33:46 +0000 (UTC) Received: from oldred.freebsd.org ([127.0.1.6]) by oldred.freebsd.org (8.14.5/8.14.7) with ESMTP id r7IFXksb001192 for ; Sun, 18 Aug 2013 15:33:46 GMT (envelope-from nobody@oldred.freebsd.org) Received: (from nobody@localhost) by oldred.freebsd.org (8.14.5/8.14.5/Submit) id r7IFXkxk001189; Sun, 18 Aug 2013 15:33:46 GMT (envelope-from nobody) Message-Id: <201308181533.r7IFXkxk001189@oldred.freebsd.org> Date: Sun, 18 Aug 2013 15:33:46 GMT From: Christopher Harrison To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: kern/181377: zfs recv causes an inconsistant pool X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2013 15:40:03 -0000 >Number: 181377 >Category: kern >Synopsis: zfs recv causes an inconsistant pool >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Aug 18 15:40:03 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Christopher Harrison >Release: 9.2-RC2 >Organization: >Environment: >Description: When receiving a large zfs send -R stream if the system is interrupted the system does not recover gracefully. The zpool will end up in an inconsistent state and not zfs list, zpool import or zpool scrub. The system will run out of available memory resources and "hang" killing all user land processes in the process. This functionality is different from prior releases as the system would "normally" roll back the inconsistent dataset to a consistent state (all bent to a prior state which might have lost data). I would be happy to provide core files Attempts to roll back the zpool to a prior transaction fall too with a zdb core dump (zdb -F z, zdb -X z). On initial check/import/list of the inconsistent pool an error is generated: Solaris: WARNING: can't open objset for z/Systems/volumes/images digging into this using zdb -dddd z/Systems/volumes/images The follow message occurs: Could not open gls/Systems/volumes/images, error 16 >How-To-Repeat: upgrade the zpool the to the latest version flags (or create a new zpool). Have a system with a smaller amount of memory (I have 8GB). Send a large zfs dataset (>100GB) to the newly created pool, after 50% complete pull the power or have a system interruption which causing the system to need to reboot. After the reboot, the system come up in an inconsistent state and quickly becomes memory starved, thus crashing over and over again. The system will consume memory without releasing any and will experience a memory starvation situation within 10min of issuing a zpool command on the inconsistent pool >Fix: >Release-Note: >Audit-Trail: >Unformatted: