Chris's Wiki :: blog/solaris/ZFSReceiveNoErrorRecovery Commentshttps://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSReceiveNoErrorRecovery?atomcommentsDWiki2017-05-10T20:57:53ZRecent comments in Chris's Wiki :: blog/solaris/ZFSReceiveNoErrorRecovery.By Chris Siebenmann on /blog/solaris/ZFSReceiveNoErrorRecoverytag:CSpace:blog/solaris/ZFSReceiveNoErrorRecovery:54b051c27e6c9bcb92c394e775bb200bcb8d2b79Chris Siebenmann<div class="wikitext"><p>Unfortunately, as far as I understand <code>zfs_send_corrupt_data</code> is for
the case where you have corrupted data on the snapshot source and you
still want to be able to '<code>zfs send</code>' a snapshot to your destination. I
don't believe it helps you if the send stream itself becomes corrupt
while you have it stored on disk or the like.</p>
</div>2017-05-10T20:57:53ZBy Anon on /blog/solaris/ZFSReceiveNoErrorRecoverytag:CSpace:blog/solaris/ZFSReceiveNoErrorRecovery:398dce0874328576e648af182148dde777227c9eAnon<div class="wikitext"><p>Hmm... I guess if you want to grab as much as you can regardless of "corruption" you could use the option mentioned in <a href="https://github.com/zfsonlinux/zfs/issues/1982">https://github.com/zfsonlinux/zfs/issues/1982</a> on the ZFS module itself? However, I admit this is getting a away from the whole automatic error recovery idea though.</p>
</div>2017-05-10T19:24:39ZBy Chris Siebenmann on /blog/solaris/ZFSReceiveNoErrorRecoverytag:CSpace:blog/solaris/ZFSReceiveNoErrorRecovery:84262049bd9925e5c1dc5c8b68c79ebec3d2e865Chris Siebenmann<div class="wikitext"><p>Without reading the changeset in detail, it's at least a partial example
of damage to a send stream. I think that a full version would somehow
force an IO read error at some point as well (to simulate things like
a ZFS filesystem that's detected a corrupt block and refuses to give it
to the '<code>zfs receive</code>').</p>
<p>Detecting the damage and reporting where is only part of the problem,
though. The troublesome bit, on both a technical and 'how it should
work' level, is how to recover from it and maximizing the amount that
you can recover.</p>
</div>2017-05-09T01:54:08ZBy Anon on /blog/solaris/ZFSReceiveNoErrorRecoverytag:CSpace:blog/solaris/ZFSReceiveNoErrorRecovery:b0ff9b9af641944f6b8b1a02759e681adf68c6b6Anon<div class="wikitext"><blockquote><p>This is fine for interruptions [...] but doesn't help if you have genuine corruption that you would have to skip over.</p>
</blockquote>
<p>Does <a href="https://github.com/illumos/illumos-gate/commit/9c3fd1216fa7fb02cfbc78a2518a686d54b48ab8#diff-5d452ee490fd0347170ea2a477f43962R22">https://github.com/illumos/illumos-gate/commit/9c3fd1216fa7fb02cfbc78a2518a686d54b48ab8#diff-5d452ee490fd0347170ea2a477f43962R22</a> show the sort of corruption you were thinking of?</p>
</div>2017-05-08T21:29:58ZBy Chris Siebenmann on /blog/solaris/ZFSReceiveNoErrorRecoverytag:CSpace:blog/solaris/ZFSReceiveNoErrorRecovery:9a847423723df3e74c5dba47a51853eab8f05041Chris Siebenmann<div class="wikitext"><p>My understanding is that resumable '<code>zfs send</code>' and '<code>zfs receive</code>'
only help if you can get an intact send stream somehow. This is fine
for interruptions (where you can resume from where things stopped),
but doesn't help if you have genuine corruption that you would have to
skip over.</p>
</div>2017-05-08T20:32:31ZBy Anon on /blog/solaris/ZFSReceiveNoErrorRecoverytag:CSpace:blog/solaris/ZFSReceiveNoErrorRecovery:961cdce7e548632de18bc9b8ee2b09eb03f099ffAnon<div class="wikitext"><p>Doesn't <a href="https://github.com/zfsonlinux/zfs/issues/3896">https://github.com/zfsonlinux/zfs/issues/3896</a> and <a href="https://www.illumos.org/issues/2605">https://www.illumos.org/issues/2605</a> address some of this?</p>
</div>2017-05-08T20:11:51Z