<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	>
<channel>
	<title>Comments on: Notes on how to speed up the trb resync process after data corruption</title>
	<atom:link href="http://ztkfg.com/2020/07/notes-on-how-to-speed-up-the-trb-resync-process-after-data-corruption/feed/" rel="self" type="application/rss+xml" />
	<link>http://ztkfg.com/2020/07/notes-on-how-to-speed-up-the-trb-resync-process-after-data-corruption/</link>
	<description>198.211.113.164 // 6326 273B 61A7 00AF 4CD9 5A7B 8C6C AB19 24A6 4DEC</description>
	<pubDate>Mon, 13 Apr 2026 17:48:46 +0000</pubDate>
	<generator>http://polimedia.us</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: whaack</title>
		<link>http://ztkfg.com/2020/07/notes-on-how-to-speed-up-the-trb-resync-process-after-data-corruption/#comment-332</link>
		<dc:creator>whaack</dc:creator>
		<pubDate>Thu, 23 Jul 2020 14:37:00 +0000</pubDate>
		<guid isPermaLink="false">http://ztkfg.com/?p=477#comment-332</guid>
		<description>Hm you're right, should have kept it. I won't be surprised if I have an opportunity to do this again in the future.</description>
		<content:encoded><![CDATA[<p>Hm you're right, should have kept it. I won't be surprised if I have an opportunity to do this again in the future.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jacob Welsh</title>
		<link>http://ztkfg.com/2020/07/notes-on-how-to-speed-up-the-trb-resync-process-after-data-corruption/#comment-329</link>
		<dc:creator>Jacob Welsh</dc:creator>
		<pubDate>Sun, 19 Jul 2020 18:49:06 +0000</pubDate>
		<guid isPermaLink="false">http://ztkfg.com/?p=477#comment-329</guid>
		<description>&#62; Remove your most recent blk000n.dat file, since it should be the file that is corrupted.

That's unfortunate - if you'd kept it, we could test the hypothesis since a corrupt block would be gracefully rejected by eatblock.</description>
		<content:encoded><![CDATA[<p>&gt; Remove your most recent blk000n.dat file, since it should be the file that is corrupted.</p>
<p>That's unfortunate - if you'd kept it, we could test the hypothesis since a corrupt block would be gracefully rejected by eatblock.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
