Date: Wed, 30 Nov 2022 07:54:00 +0100 (CET) From: Sysadmin Lists <sysadmin.lists@mailfence.com> To: questions@freebsd.org Cc: Andrea Venturoli <ml@netfence.it> Subject: Re: ZFS Permanent error <0xffffffffffffffff>:<0x0> 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> <c4d43906-d8a7-8945-abab-4e6c81e2fc6f@freebsd.org> <5def1695-82b3-3441-c11a-d64ca0c7c30a@netfence.it> <255658040.26515.1669699637761@orville.co-bxl> <47265e09-3aa0-24fa-22cb-56e09bb524f0@netfence.it>
next in thread | previous in thread | raw e-mail | index | archive | help
> ---------------------------------------- > From: Andrea Venturoli <ml@netfence.it> > Sent: Tue Nov 29 09:55:04 CET 2022 > To: Sysadmin Lists <sysadmin.lists@mailfence.com> > Cc: <questions@freebsd.org> > Subject: Re: ZFS Permanent error <0xffffffffffffffff>:<0x0> > > > On 11/29/22 06:27, Sysadmin Lists wrote: > > Hello! > > > The construct is <dataset>:<filename>. 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:<object number> 3. If the dataset has been deleted, it shows this: <dataset number>:<object number> or '<metadata>':<object number> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?597333482.1125294.1669791240602>