[zfs-discuss] Corrupted ZFS, but Scrub Shows no Errors!

Gordan Bobic gordan.bobic at gmail.com
Thu Nov 26 14:22:32 EST 2015


I have a zfs that is verifiably corrupted, but the pool containing it
scrubs out as completely clean with no errors.

Various directories/links are showing up as, for example:

# ls -la /maximilian/hammersteinROOT/boot.bak/rd/usr/
ls: cannot access /maximilian/hammersteinROOT/boot.bak/rd/usr/lib: No such
file or directory
total 17
drwxr-xr-x. 3 root root 3 Nov 26 18:19 .
drwxr-xr-x. 3 root root 3 Nov 26 18:17 ..
d?????????? ? ?    ?    ?            ? lib

This corruption survives zfs send/receive, and pools on both sides of
send/receive scrub as clean, without any errors detected.

Trying to remove the entries that show up as the above results in an
instantaneous kernel panic on both x86-64 and 32-bit ARM.

I have sanitized it as much as I can I - no files remain visible, all of
the corrupted entries show up in directories and symlinks, but removing
some of the symlinks and directories that otherwise seem OK still result in
a kernel panic when an attempt is made to rm them. This minimal-ish
zfs-send is still 12MB in size, which leads me to believe there is
something else in there that isn't showing up.

I cam provide this to any developers that are interested in poking at it to
figure out what kind of on-disk corruption can result in obviously busted
metadata than panics the kernel module yet doesn't end up being picked up
by a scrub operation.

If anybody is interested, please let me know and I'll arrange to have the
send stream uploaded somewhere.

Gordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.zfsonlinux.org/pipermail/zfs-discuss/attachments/20151126/b72e8b22/attachment.html>


More information about the zfs-discuss mailing list