From nobody Sat Sep 25 23:20:08 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 E30D617D3455 for ; Sat, 25 Sep 2021 23:20:26 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f47.google.com (mail-ot1-f47.google.com [209.85.210.47]) (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 4HH4d641b9z3rDY for ; Sat, 25 Sep 2021 23:20:26 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f47.google.com with SMTP id h9-20020a9d2f09000000b005453f95356cso18589299otb.11 for ; Sat, 25 Sep 2021 16:20:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WJd2uvBg3G9OUrE1sZBOS7dTOAMaWxSrqeR7Yqfpq7Y=; b=zRug0jnx7TRW9u/ylt2EGR9/XJzojSJUHcf6rY+9K/wHjNbYYwuXwLIHA91nsQHNtU hru36qv5CwgPdgqdkjOIMHuBbCFoY0IMhaiSg2RNPU0QEJK74/4zN3V0zjdyQrLTrQNh PzWVMaT4+k7kn+OvfIBacxuszbY0NjZ00VGj1f2dF4aDjSVfkJ9CdE6lAbjr0a+q9Ax5 9OY3Dem4+Anyoj2lbbcRq1rNbtT0l3HPO4XvLkdxOsiZjyoVIDiNKBABCeNuolaowmJ8 DdjHhhrWy+J3xNrvhHm3jPhmi2ERWuQo70fPnjc3x4moyE6IYOvk4IuUKXK8uIiMB2z5 EIUw== X-Gm-Message-State: AOAM532dU087QOCx66xLGQdnuOMjFtOb/x0mNAz2YG6wBP1ozX5iq0BE V94JyG0jqv11cFrz/oK5Q5IKyMauixSQKNN05vD26T7z X-Google-Smtp-Source: ABdhPJyTF0go2kPoP3R7oAqaQcX9nvx8uw02Hw03Ca4+WZbSKGJnI5g2cI4Vhb549TN7EvCdPXqcarEN8wAV8t9+Qtw= X-Received: by 2002:a9d:6c91:: with SMTP id c17mr10571192otr.114.1632612019609; Sat, 25 Sep 2021 16:20:19 -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: <33176b34-6929-57fb-2e3f-bd3e9396fe01@quip.cz> In-Reply-To: <33176b34-6929-57fb-2e3f-bd3e9396fe01@quip.cz> From: Alan Somers Date: Sat, 25 Sep 2021 17:20:08 -0600 Message-ID: Subject: Re: ZFS errors with two HEX numbers. To: Miroslav Lachman <000.fbsd@quip.cz> Cc: Zaphod Beeblebrox , freebsd-fs Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4HH4d641b9z3rDY X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sat, Sep 25, 2021 at 4:01 PM Miroslav Lachman <000.fbsd@quip.cz> wrote: > > On 25/09/2021 21:28, Zaphod Beeblebrox wrote: > > I've got a ZFS pool --- 3 x 8 x 4T disks in a RAIDZ2 configuration. Every > > few months I scrub them. This time, curiously, it came up with an error. > > All the disks in a vdev simultaneously give an error when this is > > scanned.... thusly: > > > > raidz2-3 ONLINE 0 0 0 > > gpt/v1-f0 ONLINE 0 0 1 > > gpt/v1-f1 ONLINE 0 0 1 > > gpt/v1-f2 ONLINE 0 0 1 > > gpt/v1-f3 ONLINE 0 0 1 > > gpt/v1-f4 ONLINE 0 0 1 > > gpt/v1-f5 ONLINE 0 0 1 > > gpt/v1-f6a ONLINE 0 0 1 > > gpt/v1-f7b ONLINE 0 0 1 > > > > ... and if I add -v to the status, I see the following right now: > > > > errors: Permanent errors have been detected in the following files: > > <0x57b2>:<0x73ab46> > > > > Now... since that happened, I have scrubbed twice more. The first number > > changes each time. Last scrub it was: <0x4223>:<0x73ab46>. Note the last > > number is not changing. > > > > I have done some googling and found that this might be something that got > > corrupted on delete or somesuch. My OCD would like to know what 0x4223 > > maps to (or now 0x57b2) s.t. I could find it and remove it. I _think_ this > > is a snapshot reference? > > I have seen this in the past. It was corruption on some deleted file > preserved on snapshot. Once I deleted snapshots this error disappeared. > > [...] > > Miroslav Lachman I believe the first number is the objset number, where the objset can be either a dataset or a snapshot. The corrupt block likely exists in multiple snapshots, but "zpool status" will show only one, whichever it happened to find first. You can see the objset numbers for datasets (but not snapshots) in the output of "sysctl kstat.zfs". The second number I believe is the object number, and that should never change.