I recently suffered a failed disk resulting in some files getting corrupted. I replaced the drive and recovered the corrupted files, however one file keeps complaining about checksum errors:
$ sudo zpool status -v | grep -v autosnap
pool: mypool
state: ONLINE
status: One or more devices has experienced an error resulting in data
corruption. Applications may be affected.
action: Restore the file in question if possible. Otherwise restore the
entire pool from backup.
see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-8A
scan: scrub repaired 0B in 04:52:52 with 20 errors on Sun Sep 28 07:52:52 2025
config:
NAME STATE READ WRITE CKSUM
mypool ONLINE 0 0 0
sda ONLINE 0 0 0
errors: Permanent errors have been detected in the following files:
mypool/mydataset:<0x52f2>
The other 20 errors are that same file, or whatever it is, in old snapshots.
Has anyone seen this before and knows how to clear that error? zpool clear mypool does nothing.
ZFS has done its job — it detected silent corruption. But because you’re using a single disk (no redundancy), it cannot fix the issue. The only fix now is restoring the corrupted files from backup.
Disclaimer: I have no experience reparing this. I have a few pools on one device but when they fail or go wrong, I restore from backup. So I you do not have backup wait to see if anyone here can help.
I’ve replaced the disk and restored from backup, the 20 unrecoverable errors are
mypool/mydataset:<0x52f2>
and 19 snapshots of that corrupt thing, the question is if anyone knows what that is, it’s not a filename in my dataset, and trying to do anything with it just results in the terminal interpreting it as the newline character. I can’t restore it from backup because it isn’t a file (I think).
I guess I could try creating a new pool and move the datasets over.
It’s a hexadecimal object ID representing the internal object number within the dataset that has an error.
ZFS stores data in a set of internal objects files, directories, metadata, extended attributes, etc., each with a unique ID. The object <0x52f2> is the one that ZFS couldn’t read or verify due to checksum errors, likely because of underlying disk issues or corruption in the storage.
Try to locate the object:
sudo zdb -dddd mypool/mydataset 0x52f2
This will attempt to show information about that object — sometimes it will give you a file path or at least tell you if it’s a directory, file, xattr, etc.
This datasets holds exported JPG’s, so by the type and size I assume it’s some random photo. The path is listed as “on delete queue”, which I haven’t been able to find information on.
and find my file in there as the only entry. The internet says that files getting stuck in the delete queue can happen if the file is open, and some people talk about having to mount-cycle the pool to have it flush the queue.
I’ve unmounted the pool, exported it, imported and mounted again with no luck, then re-booted, although this has been a problem since before last boot, and that didn’t work either.
This tool is for advanced debugging and is where my skills end. File seems to be metadata structure used by ZFS to track file deletions in progress (or pending deletion in snapshots). It’s not user data, and its presence is entirely normal in an active filesystem.
How did you restore the dataset, was it through zfs send/recv or another tool like rsync/cp command? Do you know this new device to be good?
My understanding is that when you delete a file, it goes to the ZFS delete queue, which has object ID = 33 in my dataset, and stuck in that queue is my file with object ID = 52f2 in hexadecimal or just 21234.
In any case, since there’s seemingly no way to flush the queue, I’ll try making a new dataset, which I think would have a new delete queue, and then not rsync the data over or something, so that the old delete queue doesn’t get copied over.
How did you restore the dataset, was it through zfs send/recv or another tool like rsync/cp command? Do you know this new device to be good?
zfs-send-ing the last known non-corrupted snapshot would have involved loss of some new data, and since it was only a handful of files that needed restoring, I used cp or rsync to restore individual files. I replaced the dying disk with a new Samsung EVO 1TB and no new data errors have appeared since then.
I tried rsync-ing from my backups to the new dataset and got input/output errors when doing so. I’m going to consider the pool toast, set up a new mirrored pool and restore from backup.