Well what does _that_ verify? It will verify that no bits provably broke during transport.
It will still leave the chance of getting an incompatible stream, an incomplete stream (kill the dump), or plain corrupted data. Of course, the chance of the latter should be extremely small in server-grade hardware. $0.02 Sriram Narayanan wrote: > If feasible, you may want to generate MD5 sums on the streamed output > and then use these for verification. > > -- Sriram > > On 12/5/09, Edward Ned Harvey <sola...@nedharvey.com> wrote: > >>> Depending of your version of OS, I think the following post from Richard >>> Elling >>> will be of great interest to you: >>> - >>> http://richardelling.blogspot.com/2009/10/check-integrity-of-zfs-send-streams. >>> html >>> >> Thanks! :-) >> No, wait! .... >> >> According to that page, if you "zfs receive -n" then you should get a 0 exit >> status for success, and 1 for error. >> >> Unfortunately, I've been sitting here and testing just now ... I created a >> "zfs send" datastream, then I made a copy of it and toggled a bit in the >> middle to make it corrupt ... >> >> I found that the "zfs receive -n" always returns 0 exit status, even if the >> data stream is corrupt. In order to get the "1" exit status, you have to >> get rid of the "-n" which unfortunately means writing the completely >> restored filesystem to disk. >> >> I've sent a message to Richard to notify him of the error on his page. But >> it would seem, the zstreamdump must be the only way to verify the integrity >> of a stored data stream. I haven't tried it yet, and I'm out of time for >> today... >> >> >> _______________________________________________ >> zfs-discuss mailing list >> zfs-discuss@opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >> >> > > _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
