<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>I normally watch quietly from the sidelines but I think it's important to get some balance here; our customers between them run many hundreds of multi-terabyte arrays and when something goes badly awry it generally falls to me to sort it out. In my experience xfs_repair does exactly what it says on the tin.</div><div><br></div><div>I can recall only a couple of instances where we elected to reformat and reload from backups and they were both due to human error: somebody deleted the wrong raid unit when doing routine maintenance, and then tried to fix it up hemselves.</div><div><br></div><div>In theory of course xfs_repair shouldn't be needed if the write barriers work properly (it's a journalled filesystem), but low-level corruption does creep in due to power failures / kernel crashes and it's this which xfs_repair is intended to address; not massive data corruption due to failed hardware or careless users.</div><div><br></div><div>--</div><div>Roger</div><div><br><div><br><div><div>On 9 Sep 2014, at 23:57, Sean Caron <<a href="mailto:scaron@umich.edu">scaron@umich.edu</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Hey, just sharing some hard-won (believe me) professional experience. I have seen xfs_repair take a bad situation and make it worse many times. I don't know that a filesystem fuzzer or any other simulation can ever provide true simulation of users absolutely pounding the tar out of a system. There seems to be a real disconnect between what developers are able to test and observe directly, and what happens in the production environment in a very high-throughput environment.<div><br></div><div><div>Best,</div><div><br></div><div>Sean</div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 9, 2014 at 6:24 PM, Eric Sandeen <span dir="ltr"><<a href="mailto:sandeen@sandeen.net" target="_blank">sandeen@sandeen.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 9/9/14 11:03 AM, Sean Caron wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Barring rare cases, xfs_repair is bad juju.<br>
</blockquote>
<br></span>
No, it's not. It is the appropriate tool to use for filesystem repair.<br>
<br>
But it is not the appropriate tool for recovery from mangled storage.<br>
<br>
I've actually been running a filesystem fuzzer over xfs images, randomly<br>
corrupting data and testing repair, 1000s of times over. It does<br>
remarkably well.<br>
<br>
If you scramble your raid, which means your block device is no longer<br>
an xfs filesystem, but is instead a random tangle of bits and pieces of<br>
other things, of course xfs_repair won't do well, but it's not the right<br>
tool for the job at that stage.<span class="HOEnZb"><font color="#888888"><br>
<br>
-Eric<br>
</font></span></blockquote></div><br></div>
_______________________________________________<br>xfs mailing list<br><a href="mailto:xfs@oss.sgi.com">xfs@oss.sgi.com</a><br>http://oss.sgi.com/mailman/listinfo/xfs<br></blockquote></div><br></div></div></body></html>