|
Description
|
Using stock snv_52 bits, I created a pool, and took a snapshot of it.
I then zfs sended (sent, sorry) this to a datafile. I removed the original
data in the pool and did a zfs destroy -r pool to clear the snapshots.
# zfs list extra
NAME USED AVAIL REFER MOUNTPOINT
extra 96K 9.60G 24.5K /extra
# mkfile 10m /extra/file1
# zfs snapshot extra@original
# zfs send extra@original > /tmp/extra-original.dat
# zfs destroy -r extra
On doing zfs recv -d pool/new (where pool/new doesn't exist), we get a coredump:
# zfs receive -d extra/restore < /tmp/extra-original.dat
Segmentation Fault - core dumped
# mdb core
Loading modules: [ libumem.so.1 libuutil.so.1 libnvpair.so.1 libc.so.1 libavl.so.1 ld.so.1 ]
> $c
libzfs.so.1`create_parents+0x30(80b5548, 8045d84, d)
libzfs.so.1`zfs_receive+0x693(80b5548, 8046dcf, 1, 0, 0, 0)
zfs_do_receive+0x17e(3, 8046c1c)
main+0xa0(4, 8046c18, 8046c2c)
_start+0x7a(4, 8046dc0, 8046dc4, 8046dcc, 8046dcf, 0)
> $q
I've attached the core. The command issued was user error, we should be getting
an error message to say that the destination filesystem specified by -d
doesn't exist in this case.
Now, interestingly enough, if the original archive file was taken of a
*child filesystem* of the top level filesystem, this works as expected,
and we get an error message, not a coredump:
# zfs list -r extra
NAME USED AVAIL REFER MOUNTPOINT
extra 92K 9.60G 24.5K /extra
# zfs create extra/child
# mkfile 10m /extra/child/file1
# zfs snapshot extra/child@snap1
# zfs send extra/child@snap1 > /tmp/backup.dat
# zfs destroy -r extra
# zfs recv -d extra/not-there < /tmp/backup.dat
cannot open 'extra/not-there': dataset does not exist
cannot receive: unable to restore to destination
# zfs recv -d extra/nanoo/nanoo < /tmp/backup.dat
# zfs recv -d extra/nanoo/nanoo < /tmp/extra-original.dat
Segmentation Fault - core dumped
This bug seems particular to top-level filesystems, and something in the
archived backup differs when we have a top-level backup, vs. a child
filesystem backup. I've attached these backup archives as well, if that
helps.
|
