Re: ZFS Permanent error <0xffffffffffffffff>:<0x0>

From: Sysadmin Lists <sysadmin.lists_at_mailfence.com>
Date: Wed, 30 Nov 2022 06:54:00 UTC
> ----------------------------------------
> 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