Okay. We are trying again to reproduce this on b151a.
In the meantime, you could rule out a problem with zfs send/recv on your
system if you could create another non-BE dataset with descendent
datasets, create a recursive snapshot, and retry the recursive send/recv
operation.
Thanks,
Cindy
On 01/05/11 12:21, Brandon High wrote:
On Wed, Jan 5, 2011 at 9:44 AM, Cindy Swearingen
<cindy.swearin...@oracle.com> wrote:
In your follow-up, I think you are saying that rp...@copy is a recursive
snapshot and you are able to receive the individual rpool snapshots. You
just can't receive the recursive snapshot. Is this correct?
Sorry, I didn't really explain that very well. Both pools are version
31, and the zfs version is 5.
The snapshot has been created recursively via:
# zfs snapshot -r rp...@copy
# zfs list -t snapshot -r rpool
NAME USED AVAIL REFER MOUNTPOINT
rp...@copy 0 - 3.21M -
rpool/r...@copy 0 - 24.5K -
rpool/ROOT/snv_1...@copy 1.76M - 5.61G -
Trying to send it recursively fails:
# zfs send -R rp...@copy | zfs recv -n -vduF radar/foo
Sending each of the recursively created snapshots, one at a time, works:
# for snap in $( zfs list -t snapshot -r -H -o name rpool ) ; do zfs
send $snap | zfs recv -vduF radar/foo ; done
receiving full stream of rp...@copy into radar/f...@copy
cannot receive new filesystem stream: invalid backup stream
receiving full stream of rpool/r...@copy into radar/foo/r...@copy
received 10.2KB stream in 1 seconds (10.2KB/sec)
receiving full stream of rpool/ROOT/snv_1...@copy into
radar/foo/ROOT/snv_1...@copy
received 5.51GB stream in 183 seconds (30.8MB/sec)
It looks like only the rp...@copy snapshot or the rpool dataset are
bad. All the other datasets seem to work fine.
-B
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
