From nobody Wed Jul 14 21:21:34 2021 X-Original-To: freebsd-fs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3F65A8D10FB for ; Wed, 14 Jul 2021 21:21:46 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f50.google.com (mail-ot1-f50.google.com [209.85.210.50]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GQ9Rt0ybhz4Yrg for ; Wed, 14 Jul 2021 21:21:46 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f50.google.com with SMTP id w8-20020a0568304108b02904b3da3d49e5so4036149ott.1 for ; Wed, 14 Jul 2021 14:21:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mA919zdHNQczE4ZDG6HZPReiwL2CT9As2BzptqebkpI=; b=i9Wyy5kMqs/DZ4ILrJKkxkKRe58Fh1M1Ow5QY632Ej673FvnrtOiZEAbDFsEgrsFlC hoECPTToGxeENgqA0WK7vjUZ+iD54H3bKclsdY3hmDFa0L4e1GKFYXm1IozJN1zNydeK AZ1lWxi3ydKFnISFQfmohWUwd7EosnxRM3IeLMPv0RBPtduj0WjT+2oH/AeiCOeCMmsd OIeiUUb2EhzqhEnFq1yc64dOkGmpDxRal+wgGJRcMHkyaImHhU/fraROwspbwC2BImUV ol3ww1CbJbJ/bFUOnJs/e9bKN+aWGo3b1anLk1lKWPR8BjtJnncaE7BqgwYH94SFcdMm EeXg== X-Gm-Message-State: AOAM532SPv4zv1mBZ7Ki8K2HXP9PaVHtMw9tRq9Ry+ZGDYWTpDAuNEMc GRc5TM/FIHoQEweFLSMMYpfbmLDh//XA6Z+EKPdj5zxhylQ= X-Google-Smtp-Source: ABdhPJwaPx9vcTh4J1PvFuDQMBywaWOsj3KYArHuNpbURHyNJ55yNM7uNOifrScPzOIFlCZ650Olp2bM46SCse3RpQU= X-Received: by 2002:a9d:7982:: with SMTP id h2mr140925otm.291.1626297704950; Wed, 14 Jul 2021 14:21:44 -0700 (PDT) List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Wed, 14 Jul 2021 15:21:34 -0600 Message-ID: Subject: Re: ZFS: zpool status on degraded pools (FreeBSD12 vs FreeBSD13) To: Dave Baukus Cc: "freebsd-fs@freebsd.org" Content-Type: multipart/alternative; boundary="00000000000000b17805c71bf106" X-Rspamd-Queue-Id: 4GQ9Rt0ybhz4Yrg X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --00000000000000b17805c71bf106 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 14, 2021 at 3:10 PM Dave Baukus wrote: > I'm seeking comments on the following 2 difference in the behavior of ZFS. > The first, I consider a bug; the second could be a bug or a conscious > choice: > > 1) Given a pool of 2 disks and one extra disk exactly the same as the 2 > pool members (no ZFS labels on the extra disk), > power the box off, replace one pool disk with extra disk in the same > location; power box back on. > > The pool is state on FreeBSD13 is ONLINE vs DEGRADED on FreeBSD12: > I agree, the FreeBSD 13 behavior seems like a bug. > 2.) Add a spare to a degraded pool and issue a zpool replace to activate > the spare. > On FreeBSD13 after the resilver is complete, the pool remains degraded > until the degraded disk > is removed via zpool detach; on Freebsd12, the pool becomes ONLINE when > the resilver is complete: > I agree. I think I prefer the FreeBSD 13 behavior, but either way is sensible. The change is no doubt due to the OpenZFS import in FreeBSD 13. Have you tried to determine the responsible commits? They could be regressions in OpenZFS, or they could be bugs that we fixed in FreeBSD but never upstreamed. -Alan --00000000000000b17805c71bf106--