<div dir="ltr"><span style="font-size:16px">Darrick, </span><div style="font-size:16px"><br></div><div style="font-size:16px">A million thanks! The xfs_db commands you sent worked.</div><div style="font-size:16px"><br></div><div style="font-size:16px">Here is the surgery I did. First rsync with -c was taking too long (more than a day with no reports as the data is 30+ TBs) and also --ignore-times did not give any information. </div><div style="font-size:16px"><br></div><div style="font-size:16px">So I used the xfs_db commands you had mentioned. It gave me a list of files in affected space. When I do a "diff -rq" with original data and the data in the corrupted space -- BAM! I see files are indeed different! Now I am going to delete the corrupted directory and copy from the old data archive.</div><div style="font-size:16px"><br></div><div style="font-size:16px">Thanks!</div><div style="font-size:16px"><br></div><div style="font-size:16px">Paul</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 24, 2016 at 1:12 AM, Darrick J. Wong <span dir="ltr"><<a href="mailto:darrick.wong@oracle.com" target="_blank">darrick.wong@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, Feb 23, 2016 at 10:37:36PM -0500, Paul Cannon wrote:<br>
> I have accidentally damaged my XFS, and need help (and a little prayer).<br>
> The way it happened will provide your daily amusement dose (and hopefully a<br>
> lesson).<br>
><br>
> * What happened?<br>
> I have two file systems xfsA (18 TBs on /dev/sdc1) and xfsB (36 TBs on<br>
> /dev/sdd1). They were mounted and working fine. I accidentally executed an<br>
> old script that effectively ran the following command:<br>
> >ddrescue /dev/sdc /dev/sdd sdc_sdd.log<br>
> For those unfamiliar with the ddrescue command, it claims to rescue/image<br>
> data from a drive A to B. It does multiple passes to rescue data with<br>
> maximum efficiency.<br>
><br>
> * Why did I do it?<br>
> I am careless or dumb or may be a combination of both. But the fact that<br>
> drives got remapped (sdc/sdd became sde/sdf and otherway around) might also<br>
> be part of it.<br>
><br>
> * What happened to XFS on sdd (xfsB)?<br>
> Luckily, the imaging started with an offset of about 2.7 TBs. Why? Because<br>
> this was a restart of ddrescue and it started from past point. IT WROTE a<br>
> total of 6.1 GBs of data on sdd/xfsB<br>
><br>
> So I quickly stopped as I realized my mistake. I ran xfs_repair on xfsB.<br>
> Due to the offset of 2.7 TBs, metadata seemed fine. The xfs_repair shows<br>
> everything is fine. But if I extract out data using (dd skip=2.7TB) into a<br>
> file -- I can see things are different! I recognize the abrupt change in a<br>
> text file, exactly where the data overwritten.<br>
><br>
> * Luckily I have old copy of the original data!<br>
<br>
</div></div>Good for you!  Seriously. :D<br>
<span class=""><br>
> So I did a rsync -rvn /olddata/ /xfsB<br>
> Nothing! No difference in any data files. I even tried mirrordir, same<br>
> thing -- nothing, no difference!<br>
<br>
</span>rsync -c to force it to checksum the data blocks?<br>
<br>
By default I think it only compares file size and timestamps.<br>
<span class=""><br>
> * Here is what I think is going on, and I need help.<br>
> I suspect that the access time of the file/files stored at this location<br>
> are perhaps in another location in inode (does this sound correct? I am a<br>
> newbie to XFS). But the data itself has changed at the location.<br>
<br>
</span>Quite possible.<br>
<span class=""><br>
> * QUESTION: How do I find what files were stored at the location? I have an<br>
> EXACT location of the range affected. Once I find the affected files, I can<br>
> perhaps do further surgery.<br>
<br>
</span>Sounds like something that the reverse-mapping btree and associated GETFSMAP<br>
ioctl could help solve ... too bad it only exists as experimental patches to<br>
the on-disk format. :(<br>
<br>
In the meantime, I guess you could umount the filesystem and run xfs_db on it<br>
to find out what was in the areas that got overwritten, assuming rsync -c also<br>
shows no difference.  Something along the lines of:<br>
<br>
# xfs_db /dev/sdXX<br>
xfs_db> blockget -n<br>
xfs_db> fsblock <block number of where the overwritten area starts><br>
xfs_db> blockuse -n -c <number of blocks you think got overwritten><br>
<br>
Have a look at the xfs_db manpage for more info on what those commands do.<br>
<br>
--D<br>
<span class=""><br>
><br>
> Any help (and prayers) will be highly appreciated.<br>
<br>
</span>> _______________________________________________<br>
> xfs mailing list<br>
> <a href="mailto:xfs@oss.sgi.com">xfs@oss.sgi.com</a><br>
> <a href="http://oss.sgi.com/mailman/listinfo/xfs" rel="noreferrer" target="_blank">http://oss.sgi.com/mailman/listinfo/xfs</a><br>
<br>
</blockquote></div><br></div>