Greg Bonett <greg.bon...@gmail.com> wrote: > Many months ago, I believe some *very bad hardware* caused corruption of a > file on one of my zfs file systems. I've isolated the corrupted file and > can reliably induce a kernel panic with "touch bad.file", "rm bad.file", or > "ls -l" in the bad.file's directory (ls in bad.file's dir doesn't cause > panic, but "ls bad.file" does). > > This is a raidz zpool, but zpool scrub doesn't fix it - it eventually > creates a kernel panic. > > My next plan is to attempt to get rid of this file by zfs destroy(ing) the > entire filesystem. The corrupted file is on /tank, and I've copied all of > the good data onto a new zfs file system, /tank/tempfs/.
My next plan would be reporting the problem with sufficient information so the bug can be fixed. Destroying the dataset or the whole pool seems like papering over the real issue to me and you could still do it if the PR gets ignored for too long or a developer agrees that this is the only option. Fabian
signature.asc
Description: PGP signature
