Comments on Ramblings from Richard's Ranch: check integrity of ZFS send streams with zstreamdu...

Richard, ok, filed a bug in bugster, very simple t...

2010-03-09T06:29:01.827-08:00

Richard, ok, filed a bug in bugster, very simple to reproduce, take any stream and copy the very 1st byte from it into a new file with dd, then pipe it into zstreamdump - it will exit with status code 0.

@Jonas, please file a bug and detail the steps you...

2010-03-08T14:37:27.896-08:00

@Jonas, please file a bug and detail the steps you used so that the bug can be recreated. Thanks.

Hi, just discovered the inverse of what rahvee sai...

2010-03-08T01:44:43.327-08:00

Hi, just discovered the inverse of what rahvee said - zstreamdump does not detect a modified stream (simply remove a few trailing bytes at the end of it..) and happily accepts it and exits with status 0, while zfs receive refuses it and exits with 1, so it would be impossible to recover such stream, tested on snv_133, now who/what to believe on checking the stream's integrity ?

It depends on the nature of the corruption. Regard...

2009-12-05T09:58:28.763-08:00

It depends on the nature of the corruption. Regardless, the answer is zstreamdump.

I am very interested in this, however, I confirmed...

2009-12-04T16:07:14.351-08:00

I am very interested in this, however, I confirmed one piece of wrong info you have in this blog -

If I store a zfs send, and then I intentionally corrupt it (toggle bits in the middle) and then I pipe it to "zfs receive -n" ... unfortunately I get a 0 exit status regardless of whether the data stream is actually good or bad.

In order to get a "1" exit status, the -n cannot be used. Which means of course, truly doing the restore and writing it to disk.

I will try your zstreamdump and hope for better results. :-)