Reference this: <a href="http://blogs.sun.com/bonwick/entry/casablanca">http://blogs.sun.com/bonwick/entry/casablanca</a><br>Does anyone know if we&#39;re getting ZFS anytime soon?!<br><br><div class="gmail_quote">On Wed, Jun 11, 2008 at 7:56 PM, Eric Sandeen &lt;<a href="mailto:sandeen@redhat.com">sandeen@redhat.com</a>&gt; wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">Callum Lerwick wrote:<br>
<br>
&gt; I would like to put in my +1 for this. Performance is pointless on if<br>
&gt; you can not trust that your data is safe. I have on many occasions run<br>
&gt; fscks on my supposedly clean ext3 filesystems, only to find some mild<br>
&gt; corruption. How can this happen? Isn&#39;t journaling supposed to prevent<br>
&gt; this? One day I ran a fsck before doing some filesystem resizing, only<br>
&gt; to find one of my irreplacible personal photos had become corrupted. I<br>
&gt; had no way to know when or why this file got corrupted, it had been<br>
&gt; written to disk some time ago and never touched since. I trusted<br>
&gt; journaling, and it failed me.<br>
<br>
</div>Filesystem corruption can happen for many reasons, and journaling cannot<br>
save you from them all. &nbsp;Think &nbsp;about bad cables, memory, kernel bugs,<br>
bad hardware, rogue writes to the block device, etc. &nbsp;Journaling doesn&#39;t<br>
help you in the face of any of these problems. &nbsp;If you are talking about<br>
data corruption, it could have been an application bug for example (did<br>
a photo editor corrupt it when you wrote the edited version?) &nbsp;There is<br>
a long line of things which can go wrong, unfortunately. &nbsp;Trusting<br>
journalling to keep all your data safe now and forevermore is misguided.<br>
<div class="Ih2E3d"><br>
&gt; (Yes, I have a backup. I think...) After<br>
&gt; this, I now turn on autofsck on all my machines, so that corruption at<br>
&gt; least can&#39;t go undetected for years. Which means after a power fail it<br>
&gt; takes my primary desktop with a pretty full 250gb drive 20-30 minutes to<br>
&gt; come back up, which is incredibly irritating, but I have to know my data<br>
&gt; is safe. I&#39;ve even picked up a habit of obsessively checksumming all my<br>
&gt; really important files. I wish the filesystem would help do this for me.<br>
&gt; (ZFS...)<br>
&gt;<br>
&gt; Knowing is half the battle. See, what can happen here, is a file can get<br>
&gt; corrupted, and I may not notice until years later. By then I may have<br>
&gt; cycled through several full backups, and long since lost the backup I<br>
&gt; did have of the file...<br>
&gt;<br>
&gt; This must be fixed. Only through a long painful process of losing faith<br>
&gt; have I learned to not trust my filesystems. I suspect there are many<br>
&gt; others out there who have been bitten by filesystem corruption and just<br>
&gt; don&#39;t know it yet.<br>
&gt;<br>
&gt; Only now do I learn the likely reason for this corruption. How would I<br>
&gt; have reported this? I just assumed it was hardware glitches.<br>
<br>
</div>True, corruption from out-of-order writes due to lack of barriers is<br>
hard to identify as such. &nbsp;But unfortunately there are a few other<br>
things that could have gone wrong too. &nbsp;There are things in the works to<br>
help on the integrity front, though (see<br>
<a href="http://oss.oracle.com/projects/data-integrity/" target="_blank">http://oss.oracle.com/projects/data-integrity/</a> for example).<br>
<div><div></div><div class="Wj3C7c"><br>
-Eric<br>
<br>
--<br>
fedora-devel-list mailing list<br>
<a href="mailto:fedora-devel-list@redhat.com">fedora-devel-list@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/fedora-devel-list" target="_blank">https://www.redhat.com/mailman/listinfo/fedora-devel-list</a><br>
</div></div></blockquote></div><br>