Add Optical Recovery blog post.
This commit is contained in:
Cutieguwu
144
src/blog/posts/5_optical_recovery.html
Normal file
144
src/blog/posts/5_optical_recovery.html
Normal file
@@ -0,0 +1,144 @@
|
|||||||
|
<!doctype html>
|
||||||
|
|
||||||
|
<html lang="en-ca">
|
||||||
|
<head>
|
||||||
|
<title>Optical Recovery | Cutieguwu</title>
|
||||||
|
<include src="includes/meta.html" />
|
||||||
|
</head>
|
||||||
|
<body>
|
||||||
|
<nav class="pane">
|
||||||
|
<include src="includes/nav_header.html" />
|
||||||
|
<include src="includes/nav_menu.html" />
|
||||||
|
<div class="location">
|
||||||
|
<header><h4>You are here:</h4></header>
|
||||||
|
<h5 class="page">Blog - Optical Recovery</h5>
|
||||||
|
</div>
|
||||||
|
<include src="includes/nav_quick_links.html" />
|
||||||
|
</nav>
|
||||||
|
<main class="pane blog">
|
||||||
|
<div class="body">
|
||||||
|
<header>
|
||||||
|
<h1 class="title">Optical Recovery</h1>
|
||||||
|
<p class="date">Posted: 10 January, 2026</p>
|
||||||
|
<p class="date">Last Edited: 10 January, 2026</p>
|
||||||
|
</header>
|
||||||
|
<div class="body">
|
||||||
|
<p>
|
||||||
|
Data preservation is increasingly threatened in the digital age. That almost
|
||||||
|
sounds backwards, until you dig into modern architecture.
|
||||||
|
</p>
|
||||||
|
<p>
|
||||||
|
Once upon a time, the greatest threat to information preservation was nature
|
||||||
|
and memory retrieval errors. The digital age introduced denser,
|
||||||
|
longer-lasting forms of data storage. As we progressed from punch card, to
|
||||||
|
tape, to 8 inch floppies, to flash and optical, and ever denser forms of
|
||||||
|
all, we got better at preventing data loss. Quality control, error
|
||||||
|
correction techniques bundled with file systems, and redundancy (parity) in
|
||||||
|
storage virtualizations, like RAID.
|
||||||
|
</p>
|
||||||
|
<p>
|
||||||
|
But in the modern age, the Enshittocene<sup>1</sup>, some would call it,
|
||||||
|
consumers are ever strongarmed into corporate-controlled cloud storage. With
|
||||||
|
that, comes a lack of ownership.
|
||||||
|
</p>
|
||||||
|
<p>
|
||||||
|
Now, normally that's the lead-up to advocating for homelabbing, FOSS, and
|
||||||
|
de-Googling. However, in this instance, it's the lead up to optical media
|
||||||
|
preservation. Why? Because optical media remains a great storage medium
|
||||||
|
today. Even if you don't believe that, many old games in their original
|
||||||
|
form, or other preserved media, are still only available on discs.
|
||||||
|
</p>
|
||||||
|
<p>
|
||||||
|
However, discs are subject to natural degradation through scratches,
|
||||||
|
delamination, and disc rot. Especially as the quality control on these discs
|
||||||
|
dwindles. Thus, there must be additional work put into caring for this
|
||||||
|
medium.
|
||||||
|
</p>
|
||||||
|
<p>
|
||||||
|
RAID arrays are great as alternatives too, as they already have parity,
|
||||||
|
ddrescue, and error-correcting filesystems available. The problem is that
|
||||||
|
the arrays themselves are not. At least not right now. Once again, partly
|
||||||
|
thanks to AI datacentres demanding obscene amounts of resources, the cost of
|
||||||
|
hard drives has gone up significantly since the pandemic.
|
||||||
|
</p>
|
||||||
|
<p>
|
||||||
|
With that, we segue into my latest project, temporarily named
|
||||||
|
<em>Kramer</em>. I know I did some research to come up with that name, but I
|
||||||
|
genuinely don't recall who it was in reference to. In fact, having tried
|
||||||
|
tracking down who it's in reference to, I may have messed up when I picked
|
||||||
|
the name. My best guess is that it's in reference to Kane Kramer, but he
|
||||||
|
helped design the Digital Audio Player, not optical media.
|
||||||
|
</p>
|
||||||
|
<p>
|
||||||
|
Regardless, it's always been a working name while I figure out if I can
|
||||||
|
finish the project.
|
||||||
|
</p>
|
||||||
|
<p>So, what is Kramer?</p>
|
||||||
|
<p>
|
||||||
|
Kramer is a recovery utility. Conceptually, it's meant to be akin to
|
||||||
|
ddrescue<sup>2</sup>, but optimized for recovering data from optical media.
|
||||||
|
</p>
|
||||||
|
<p>
|
||||||
|
There are two main problems I've experienced while trying to use ddrescue
|
||||||
|
with optical drives, and both stem from the drive's firmware. Now, I don't
|
||||||
|
know if me using the <code>--reset-slow</code> flag is contributing to these
|
||||||
|
issues or not, but I experience more problems without it.
|
||||||
|
</p>
|
||||||
|
<p>
|
||||||
|
If you've ever tried working with optical media in Linux, you may be
|
||||||
|
familiar with <em>The Sleep Bug</em>. Normally, this is when a drive's
|
||||||
|
firmware decides to sleep after two minutes, and never wakes. In the case of
|
||||||
|
ddrescue, I've noticed that the drive often sleeps after read errors. When
|
||||||
|
this happens, I can't kill ddrescue, and it just hangs. Even if I forcefully
|
||||||
|
disconnect the drive, it just hangs, awaiting a response from the block
|
||||||
|
device.
|
||||||
|
</p>
|
||||||
|
<p>
|
||||||
|
For the record, Kramer still has this issue. I've only recently gotten
|
||||||
|
mapping working alongside directIO to get around the Linux kernel's read
|
||||||
|
poisoning.
|
||||||
|
</p>
|
||||||
|
<p>
|
||||||
|
Keep in mind that I know very little C, and I don't play this low in the
|
||||||
|
system much yet. So, I don't know why, but without the
|
||||||
|
<code>O_DIRECT</code> flag to bypass the kernel's buffer (and whatever else
|
||||||
|
directIO technically bypasses), after a single IO error, the kernel will
|
||||||
|
refuse to return anything but that same IO error until the parent process is
|
||||||
|
restarted. I tried doing the C calls directly through FFI, since poisoning
|
||||||
|
is something that Rust employs in some places for safety. That didn't work,
|
||||||
|
so I tried spawning a child process to execute the read, but that also
|
||||||
|
didn't work. Thankfully, I know a guy, and with his help I was able to track
|
||||||
|
down not only how to implement directIO, but also without using FFI to call
|
||||||
|
<code>posix_memalign</code>.
|
||||||
|
</p>
|
||||||
|
<p>
|
||||||
|
Back on track, the other issue is the spin-down. As ddrescue reads smaller
|
||||||
|
clusters and/or starts hitting a particularly poor section of the disc, some
|
||||||
|
drives' firmware is too quick to spin down, causing the spindle to
|
||||||
|
constantly speed up and slow down, increasing wear.
|
||||||
|
</p>
|
||||||
|
<hr />
|
||||||
|
<ol>
|
||||||
|
<li>
|
||||||
|
I would recommend reading <em>Enshittification</em> by Cory Doctorow.
|
||||||
|
</li>
|
||||||
|
<li>
|
||||||
|
As I'm writing Kramer in Rust, I also have to stress the point that this
|
||||||
|
project is not intended as a ddrescue rewrite in rust, for the sake of a
|
||||||
|
rewrite in rust. I'm not trying to clone or replace ddrescue. Kramer has
|
||||||
|
a different target, and ddrescue is a resource for me to learn from and
|
||||||
|
use as a guide while I dig deeper into the system than I ever have.
|
||||||
|
</li>
|
||||||
|
</ol>
|
||||||
|
</div>
|
||||||
|
</div>
|
||||||
|
<include src="includes/tailer.html" />
|
||||||
|
</main>
|
||||||
|
<div class="pane spacer">
|
||||||
|
<include src="./includes/blog_recent_posts.html" />
|
||||||
|
<div class="spacer_container"><p>#AD</p></div>
|
||||||
|
</div>
|
||||||
|
<include src="includes/footer.html" />
|
||||||
|
<include src="includes/scripts.html" />
|
||||||
|
</body>
|
||||||
|
</html>
|
||||||
@@ -9,6 +9,16 @@
|
|||||||
</description>
|
</description>
|
||||||
<language>en-ca</language>
|
<language>en-ca</language>
|
||||||
<category>Technology/IT/Life/Mental Health/Health</category>
|
<category>Technology/IT/Life/Mental Health/Health</category>
|
||||||
|
<item>
|
||||||
|
<title>Optical Recovery</title>
|
||||||
|
<pubDate>10 January, 2026</pubDate>
|
||||||
|
<link>https://www.cutieguwu.ca/blog/posts/5_optical_recovery.html</link>
|
||||||
|
<description>Introducing my optical media recovery utility, and some challenges in development.</description>
|
||||||
|
<category>Coding</category>
|
||||||
|
<category>Programming</category>
|
||||||
|
<category>Optical Media</category
|
||||||
|
<category>Rust</category>
|
||||||
|
</item>
|
||||||
<item>
|
<item>
|
||||||
<title>Pointless Plans</title>
|
<title>Pointless Plans</title>
|
||||||
<pubDate>18 December, 2025</pubDate>
|
<pubDate>18 December, 2025</pubDate>
|
||||||
|
|||||||
@@ -1,6 +1,15 @@
|
|||||||
<div class="spacer_container blog_recent_posts">
|
<div class="spacer_container blog_recent_posts">
|
||||||
<h2>Recent Posts</h2>
|
<h2>Recent Posts</h2>
|
||||||
<div class="section_list">
|
<div class="section_list">
|
||||||
|
<section>
|
||||||
|
<header>
|
||||||
|
<div>
|
||||||
|
<h3 class="name">Optical Recovery</h3>
|
||||||
|
<span class="subtitle">10 January, 2026</span>
|
||||||
|
</div>
|
||||||
|
<a href="/blog/posts/5_optical_recovery.html" class="status">View</a>
|
||||||
|
</header>
|
||||||
|
</section>
|
||||||
<section>
|
<section>
|
||||||
<header>
|
<header>
|
||||||
<div>
|
<div>
|
||||||
|
|||||||
Reference in New Issue
Block a user