XFS Recovery Behaviour

[Andy Bennett <andyjpb@ashurst.eu.org>]

Hi,

This post isn't going to be too detailed as I ended up in a recovery
situation and was focused on checking the integrity of my files rather
than recording every step as I went.

I thought it was worth reporting as the file system seemed to recover in
an odd way.

I am not expecting any assistance as I was able to recover all my data.



I am using an XFS partition for storing my digital camera photos. I have
2 cards, card-1 and card-2. On any day when I injest the contents of the
cards I make directories import-YYYY-MM-DD/card-{1,2}/
I have a script that creates the directories and performs the injesting.

I had previously (2012/07/04) injested import-2012-07-04/card-1/

On 2012-07-28 I went into import-2012-07-04/ and created a thumbnail
gallery with my thumbnail script. This involved creating a directory
import-2012-07-05/gal-card-1 and populating it with files. The directory
entry for import-2012-07-04 was now dirty.

Simultaneously, I began a fresh injest session into
import-2012-07-28/card-2/.

Whilst these two jobs were running I suffered a hard power failure as I
unplugged the thing (it's a laptop) not realising that my battery was
flat. :-(

When I rebooted I noticed that import-2012-07-04 was showing up somewhat
thusly in 'ls -la':
-----
?????????? ? ? ?   ?? ???  ? ??:?? import-2012-07-04
-----

I could not 'cd' into it nor could I 'cat' it.
I thought the directory was lost and resolved to restore it from backups
when I returned home.

I didn't pay much attention at the time to the contents of
import-2012-07-28/

Over the course of the day I injested a few more things into
import-2012-07-28/



When I returned home I looked into restoring the backups. To my
surprise, import-2012-07-04/ was showing up as a valid directory again.
Even more surprisingly it contained a (somewhat corrupt) card-2/
directory that should have been in import-2012-07-28/. It did not
contain the card-1/ directory.

There is anecdotal evidence that import-2012-07-28/card-2/ was no longer
present.

I recovered import-2012-07-04/card-1/ from an xfsdump.

I recovered import-2012-07-28/card-2/ because I hadn't gotten around to
verifying the injest so didn't format the card before I reused it. It
wasn't full so I added more shots to it and injested it again later in
the day.


Today, I deleted import-2012-07-04/card-2/ after much to-ing and
fro-ing. It was a subset of import-2012-07-28/card-2b/ (an injest of the
same card later in the day, albeit with extra files) and some of the
overlapping files were corrupt or empty in 2012-07-04/card-2/. (My
injest script records checksums and I used a visual verification of the
images I was concerned about.)
The corrupt & missing files were the ones towards the end of the injest:
they had high numbered filenames, so would have been the ones in flight
at the time of the power failure.



I'm running XFS on Debian Testing (Wheezy)

-----
$ dpkg -l |grep xfs | grep -v x11
ii  xfsdump     3.0.6    Administrative utilities for the XFS filesystem
ii  xfslibs-dev 3.1.7+b1 XFS filesystem-specific static libraries and
headers
ii  xfsprogs    3.1.7+b1 Utilities for managing the XFS filesystem
-----

-----
$ uname -a
Linux lago 3.2.0-3-amd64 #1 SMP Thu Jun 28 09:07:26 UTC 2012 x86_64
GNU/Linux
-----

I have "defaults" under "options" in /etc/fstab.

I'm using Debian defaults on a Lenovo Thinkpad X200 laptop.


I didn't expect to see the import-2012-07-04/ directory again and I
certainly didn't expect to see it populated with the card-2/ subdirectory.






Regards,
@ndy

-- 
andyjpb@ashurst.eu.org
http://www.ashurst.eu.org/
0x7EBA75FF

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs