From nobody Wed Nov 30 06:54:00 2022 X-Original-To: questions@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 4NMVL765l8z4j22R for ; Wed, 30 Nov 2022 06:54:07 +0000 (UTC) (envelope-from sysadmin.lists@mailfence.com) Received: from mailout-l3b-97.contactoffice.com (mailout-l3b-97.contactoffice.com [212.3.242.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NMVL73Zp4z42bS for ; Wed, 30 Nov 2022 06:54:07 +0000 (UTC) (envelope-from sysadmin.lists@mailfence.com) Authentication-Results: mx1.freebsd.org; none Received: from ichabod.co-bxl (ichabod.co-bxl [10.2.0.36]) by mailout-l3b-97.contactoffice.com (Postfix) with ESMTP id 346703442; Wed, 30 Nov 2022 07:54:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1669791243; s=20210208-e7xh; d=mailfence.com; i=sysadmin.lists@mailfence.com; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; l=2343; bh=pqtYaU4BjZSoENOyRsL7Mmsyv/yvdMMTliZ8Nf/4heI=; b=FXeZt85cOYnXbvwrj0y2tlaDhazt23Xb6RuS8QrM+QhQGPiNGQ3J/szKYIAgmqV2 hBXFgGgWq7OlK48WElaUHVyjP9TXjrg+NNbyvwO6vpbXbUv+fDiGLs8eLivQm6U6ZS1 II6/ZIRglszMij9tFgsuONJghGBdRGlNjPA2xlYhFTDcKuEplz0ACZJwx603AXvj80K cHN/rf64JIBK5eIp03xD3liGbiRlGVpzbbdknNoJJQS9vevGKISy6b7mluVqc+cMGtg +R6MLjDS/59+kENoq/NRfypWEEXrO2ojrkTlgi03qZiq6w2SGR6jXQssQ8rEvsYYzH1 l3q33mwYgA== Date: Wed, 30 Nov 2022 07:54:00 +0100 (CET) From: Sysadmin Lists To: questions@freebsd.org Cc: Andrea Venturoli Message-ID: <597333482.1125294.1669791240602@ichabod.co-bxl> In-Reply-To: <47265e09-3aa0-24fa-22cb-56e09bb524f0@netfence.it> References: <0ddaa537-ffa9-af0d-1a5a-1874a67ed2b5@netfence.it> <5def1695-82b3-3441-c11a-d64ca0c7c30a@netfence.it> <255658040.26515.1669699637761@orville.co-bxl> <47265e09-3aa0-24fa-22cb-56e09bb524f0@netfence.it> Subject: Re: ZFS Permanent error <0xffffffffffffffff>:<0x0> List-Id: User questions List-Archive: https://lists.freebsd.org/archives/freebsd-questions List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: ContactOffice Mail X-ContactOffice-Account: com:312482426 X-Rspamd-Queue-Id: 4NMVL73Zp4z42bS X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:10753, ipnet:212.3.242.64/26, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N > ---------------------------------------- > From: Andrea Venturoli > Sent: Tue Nov 29 09:55:04 CET 2022 > To: Sysadmin Lists > Cc: > Subject: Re: ZFS Permanent error <0xffffffffffffffff>:<0x0> > > > On 11/29/22 06:27, Sysadmin Lists wrote: > > Hello! > > > The construct is :. It looks like you deleted the dataset > > the corrupted file was found on, so now ZFS displays it as that string. > > This is useful info. > Could the meaning of "dataset" include snapshots too? > I don't think I deleted a dataset, but I've got automatical periodical > snapshotting (of course deleting old ones). > > Scratching my head here... > If I had a corrupted file on a dataset: first, why was it not detected > earlier? > Second, if I delete that dataset, why didn't the (corrupted) file go > away with it? (If a dataset does not exist anymore, how can it still > have files?) > > > > > You can check `zpool history' for what it was called. > > Unfortunately, it's quite hard: > # zpool history zroo2 | grep "2022-11-2[56].*destroy"|wc > 802 3229 61694 > > > > > Bottom of the page here: > > https://docs.oracle.com/cd/E19253-01/819-5461/gbctx/index.html > > Sorry, but I don't get it. > Unless I'm missing something, it describes what to do when a file (or > its metadata) is corrupted; you say the corrupted file was on a > destroyed dataset. So I do I "move" or "delete" it now, if I cannot > address it??? > > bye & Thanks > av. The rules appear to be: 1. If the file metadata is intact, it shows the full mount path to the file: /path/to/filename 2. If the metadata is corrupted but the dataset still exists, it shows this: full/dataset/name: 3. If the dataset has been deleted, it shows this: : or '': IIRC, snapshots are valid entries. Perhaps the corrupted file is still associated with other snapshots. You might need to use `zdb' to find it and delete it from the filesystem, or maybe a `find /dataset/mount/point/' will trigger an abort on the inode that is corrupted. You can search inside the '/dataset/mount/point/.zfs/snapshot/' directory. -- Sent with https://mailfence.com Secure and private email