freebsd stable - Dec 2012 - how to destroy zfs parent filesystem without destroying children - corrupted file causing kernel panick

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/.

However, I can't figure out how to destroy the /tank filesystem without
destroying /tank/tempfs (and the other /tank children).  Is it possible to
destroy a parent without destroying the children? Or, create a new parent
zfs file system on the same zpool and move the /tank children there before
destroying /tank?

/tank and it's children are about 4.2 TB and I don't have the disk space
readily available to copy the whole thing (but I can get the space if it's
the only way to do this).

Thanks in advance for the help.

--Greg

system info:
FreeBSD 9.1-PRERELEASE #1 r243694
amd64
16GB ram

'zpool upgrade' gives:
This system supports ZFS pool feature flags.
All pools are formatted using feature flags.
Every feature flags pool has all supported features enabled.

'zfs upgrade' gives:
This system is currently running ZFS filesystem version 5.
All filesystems are formatted with the current version.

On Fri, Dec 28, 2012 at 12:46 PM, Greg Bonett <greg.bonett at gmail.com>
wrote:
> However, I can't figure out how to destroy the /tank filesystem without
> destroying /tank/tempfs (and the other /tank children).  Is it possible to
> destroy a parent without destroying the children? Or, create a new parent
> zfs file system on the same zpool and move the /tank children there before
> destroying /tank?
>
It is possible in case parent is not the top-most zfs filesystem (i.e
tomp-most filesystem for the pool).

I.e. if your zfs filesystem layout looked like zfs-pool/tank/tempfs, then
you could simply do "zfs rename zfs-pool/tank/tempfs zfs-pool/tempfs"
and
then would be free to remove zfs-pool/tank. Alas this rename semantics
breaks down when you can no longer rename sub-filesystem upward. I don't
think ZFS would allow you to promote inner filesystem to a pool which is
what you seem to want.

--Artem

On Fri, Dec 28, 2012 at 2:46 PM, Greg Bonett <greg.bonett at 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).
>
Does:

cat /dev/null > bad.file

Cause a kernel panic?

-- 
DISCLAIMER:

No electrons were maimed while sending this message. Only slightly bruised.

Greg Bonett <greg.bonett at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL:
<http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20121230/b896631c/attachment.sig>