Re: ZFS Permanent error <0xffffffffffffffff>:<0x0>
- Reply: Steve O'Hara-Smith : "Re: ZFS Permanent error <0xffffffffffffffff>:<0x0>"
- Reply: Andrea Venturoli : "Re: ZFS Permanent error <0xffffffffffffffff>:<0x0>"
- In reply to: Andrea Venturoli : "Re: ZFS Permanent error <0xffffffffffffffff>:<0x0>"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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