From owner-freebsd-stable@freebsd.org Fri Jul 22 13:39:05 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4F347BA0426 for ; Fri, 22 Jul 2016 13:39:05 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DC1261DE0 for ; Fri, 22 Jul 2016 13:39:04 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by mail-wm0-x22a.google.com with SMTP id o80so67103302wme.1 for ; Fri, 22 Jul 2016 06:39:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=4EzEl+j3xg6/wta7wNVfB0IruMANMnHQh9HceBo9yE8=; b=V31VSGNHNuGWIIRqsimaWr1fuytlXsd/3jsr5Zkkhdi+o3c31HrMpy7UVPk7+9EhE/ ZvH1qhi1nPjqYVbMupv0bVTVWBoB83zqm2vyXuMH4GO4CZ9IvK+OFhvIZFGQumFRZJDA 3lDHbb7qZJA3b7UrwRNZLHJUt+tnLKgQs2bj27EJJuyg/5Fhh5Qz0zzcH7cOLiHuInYa 7uwhq38ChF+Gmb6UDjWu6Oq2xxXKHvhoSxh5Tk/H7PsC3mzDgJ19zhJlGcSeNEPBHTO3 7nI1Jbqmu8h5zbaCW57+mKv+8NB4s4NKSM68hQItLrmKPh0CiLKT4FPZCTVTSDsLT/cH 4Uxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=4EzEl+j3xg6/wta7wNVfB0IruMANMnHQh9HceBo9yE8=; b=QuecMMirhdmnvKCEN6QN2ErM9Ie1cvmAL2ZcJIX31QNkCApq5qnhQSqPZbBGd06L/V +FVHLkczM5F78GNH92VI2ATRzJs5Y7j5adowM6DT/teE2wkar/2hgTjHJPdacwgLBvsd 8kuEoRJjwUcVYxGcuQfb7YeB1tWpxYiDIoXCDEyKWETVFSjX8whFUpAxgSVDBJRoDyWx zzWSkha74+36yLFpMnZA+XeZTlx1Eb5sbpAAHzv90X6d1vnGLXcc+ke2DheYF5QWzKpr eCk2rR+I5O1cuCeaBq6WUUPQQvVaXbHvPPYFIA6HAKj8ttMOEmXJj46upJWkvcoqRPYT D+MQ== X-Gm-Message-State: AEkoouvMw/vBF95TGvaIzqZsyAUsRPiD3OFjNf5Pw2zgYrdtiU+YoQFfV8PQFz7V4PoGpRDA X-Received: by 10.194.113.9 with SMTP id iu9mr1045867wjb.118.1469194742353; Fri, 22 Jul 2016 06:39:02 -0700 (PDT) Received: from [10.10.1.58] (liv3d.labs.multiplay.co.uk. [82.69.141.171]) by smtp.gmail.com with ESMTPSA id n131sm9601579wmd.3.2016.07.22.06.39.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Jul 2016 06:39:01 -0700 (PDT) Subject: Re: Panic on BETA1 in the ZFS subsystem To: Andriy Gapon , Karl Denninger , freebsd-stable@FreeBSD.org References: <8f44bc09-1237-44d0-fe7a-7eb9cf4fe85b@denninger.net> <54e5974c-312e-c33c-ab83-9e1148618ddc@FreeBSD.org> <97cf5283-683b-83fd-c484-18c14973b065@denninger.net> <1f064549-fa72-fe9b-d66d-85923437bb9b@denninger.net> <6cb46059-85c8-0c3b-7346-773647f1a962@FreeBSD.org> From: Steven Hartland Message-ID: <89b66fd6-09d8-d8a2-4894-3a6e5f73a0bb@multiplay.co.uk> Date: Fri, 22 Jul 2016 14:39:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <6cb46059-85c8-0c3b-7346-773647f1a962@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 13:39:05 -0000 On 21/07/2016 13:52, Andriy Gapon wrote: > On 21/07/2016 15:25, Karl Denninger wrote: >> The crash occurred during a backup script operating, which is (roughly) >> the following: >> >> zpool import -N backup (mount the pool to copy to) >> >> iterate over a list of zfs filesystems and... >> >> zfs rename fs@zfs-base fs@zfs-old >> zfs snapshot fs@zfs-base >> zfs send -RI fs@zfs-old fs@zfs-base | zfs receive -Fudv backup >> zfs destroy -vr fs@zfs-old >> >> The first filesystem to be done is the rootfs, that is when it panic'd, >> and from the traceback it appears that the Zio's in there are from the >> backup volume, so the answer to your question is "yes". > I think that what happened here was that a quite large number of TRIM > requests was queued by ZFS before it had a chance to learn that the > target vdev in the backup pool did not support TRIM. So, when the the > first request failed with ENOTSUP the vdev was marked as not supporting > TRIM. After that all subsequent requests were failed without sending > them down the storage stack. But the way it is done means that all the > requests were processed by the nested zio_execute() calls on the same > stack. And that lead to the stack overflow. > > Steve, do you think that this is a correct description of what happened? > > The state of the pools that you described below probably contributed to > the avalanche of TRIMs that caused the problem. > Yes does indeed sound like what happened to me. Regards Steve