<br><br><div class="gmail_quote">On Tue, May 7, 2013 at 3:20 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">

<div class="im">On 5/7/13 4:27 AM, Filippo Stenico wrote:<br>
> Hello,<br>
</div><div class="im">> this is a start-over to try hard to recover some more data out of my raid5 - lvm - xfs toasted volume.<br>
> My goal is either to try the best to get some more data out of the volume, and see if I can reproduce the segfault.<br>
> I compiled xfsprogs 3.1.9 from deb-source. I ran a xfs_metarestore to put original metadata on the cloned raid volume i had zeroed the log on before via xfs_repair -L (i figured none of the actual data was modified before as I am just working on metadata.. right?).<br>


> Then I ran a mount, checked a dir that I knew it was corrupted, unmount and try an xfs_repair (commands.txt attached for details)<br>
> I went home to sleep, but at morning I found out that kernel paniced due "out of memory and no killable process".<br>
> I ran repair without -P... Should I try now disabling inode prefetch?<br>
> Attached are also output of "free" and "top" at time of panic, as well as the output of xfs_repair and strace attached to it. Dont think gdb symbols would help here....<br>
><br>
<br>
><br>
<br>
</div>Ho hum, well, no segfault this time, just an out of memory error?<br></blockquote><div>That's right....<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


No real way to know where it went from the available data I think.<br>
<br>
A few things:<br>
<br>
> root@ws1000:~# mount /dev/mapper/vg0-lv0 /raid0/data/<br>
> mount: Structure needs cleaning<br>
<br>
mount failed?  Now's the time to look at dmesg to see why.<br>
 </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>From attached logs it seems to be:<br>
<br>
> XFS internal error xlog_valid_rec_header(1) at line 3466 of file [...2.6.32...]/fs/xfs/xfs_log_recover.c<br>
> XFS: log mount/recovery failed: error 117<br>
<br>
> root@ws1000:~# mount<br>
<br>
<no raid0 mounted><br>
<br>
> root@ws1000:~# mount /dev/mapper/vg0-lv0 /raid0/data/<br>
> root@ws1000:~# mount | grep raid0<br>
> /dev/mapper/vg0-lv0 on /raid0/data type xfs (rw,relatime,attr2,noquota)<br>
<br>
Uh, now it worked, with no other steps in between?  That's a little odd.<br>
</blockquote><div>Looks odd to me too. But i just copied the commands issued as they where on my console... so yes, nothing in between.  <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

It found a clean log this time:<br>
<br>
> XFS mounting filesystem dm-1<br>
> Ending clean XFS mount for filesystem: dm-1<br>
<br>
which is unexpected.<br>
<br>
So the memory consumption might be a bug but there's not enough info to go on here.<br>
<div class="im"><br>
> PS. Let me know if you wish reports like this one on list.<br>
<br>
</div>worth reporting, but I'm not sure what we can do with it.<br>
Your storage is in pretty bad shape, and xfs_repair can't make something out<br>
of nothing.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Eric<br></font></span></blockquote><div> </div></div>I still got back around 6TB out of 7.2 TB of total data stored, so this tells xfs is reliable even when major faults occur...<br><br>Thanks anyways, I am trying with a "-L" repair, at this step I expect another fail (due out of memory or something, as it happened last time) then I will try with "xfs_repair -L -vv -P" and I expect to see that segfault again.<br>

<br>Will report next steps, maybe something interesting for you will pop up... for me is not a waste of time, since this last try is worth being made. <br><br>-- <br>F