Another case of accidentally assigning data to parity

[Treytor]

I've been having a hell of a time converting my array to xfs, losing parity and having 3 drives die on me in the process. I've accepted the fact that some data has been lost. But in the process of all of this I had a momentary lapse of judgement and accidentally assigned an xfs formatted data drive to parity. I stopped it almost immediately when I realized the "real" parity drive wasn't mounting but it got about 4-5,000 writes in before I could.

 

Right now it sees an xfs partition, but I cannot mount it.

 

I do NOT currently have an active parity drive (I know, I know) so I can't fix and rebuild the drive.

 

I'm running unraid 6.1.9, and I know technically the parity drive doesn't have a "file system", but is a new parity drive formatted in xfs? I'm wondering if the existing (corrupted) partition is the "old" xfs, or the new one that started getting written during a parity sync.

 

I tried using testdisk to recover the partition, but wasn't exactly sure what I was doing there. I also tried photorec and that started, but the files it was recovering were strange and not named what they were originally at all. The drive had some large mkv files on it, but it was recovering lower resolution "clips" of those files as avi, which I thought was very peculiar.

 

I decided to cancel that and put the drive back into my server (unassigned) and it's currently doing an xfs_repair and taking forever to scan for a secondary superblock. In my experience during all this that never ends well, however.

 

Any new experiences with xfs_repair and any tips, or did I just lose more data during this whole debacle?

 

Thanks!

 

P.S. I think a check should be added that if a parity drive is assigned that has an existing file system, it should confirm that you actually want to do this.

 

[trurl]

You already seem to know about attempting filesystem repair.

 

What led you to believe 3 drives "died"?

 

Can't hurt to post diagnostics.

[Treytor]

Well they are currently out of my server sitting on my desk queued up to manually try recovering some data from my windows machine, so diagnostics won't tell us anything now unfortunately. But they were all failing SMART reports and tests (And all the same brand interestingly enough: Stay away from Seagate Barracuda 3TB drives!)

 

If I documented this whole mess of trial and error over the past 2 weeks, it would be several pages long. /s

 

It's just been a mess. Partly my fault, partly faulty hardware at the worst times. This most recent mess-up was totally my fault, in a different way (data and parity drive both being identical brands and models with similar serial numbers too), and was just wondering if there was anything I might be missing.

 

Once this scan finishes (And fails, I'm predicting) I will take another go at it using TestDisk to try and repair the partition, unless something else is suggested.

 

I'm quite inexperienced with linux... What's the best way to go about installing TestDisk to my unraid server?

 

I'm just not sure what those few seconds of attempting a new parity-sync on the data drive did.

 

In my completely uneducated and ignorant opinion, I really like how fast XFS is (20 resierFS drives were causing my server to completely lock up, see my previous post about that), but XFS seems like a very "brittle" filesystem. One wrong move and the whole thing goes to crap.

 

ResierFS at least seemed a bit more resilient with corruption.

 

 

[Treytor]

As I suspected, xfs_repair didn't fix anything. I figured out how to install TestDisk on my server and am now running it.

 

How do I know what partition table type to choose? TestDisk is detecting EFI GPT, but another thread here says to choose Intel... Which is it?

[garycase]

... I'm just not sure what those few seconds of attempting a new parity-sync on the data drive did.

 

Unfortunately they totally destroyed the initial sectors of the disk, where the key file system descriptors and boot block info is all stored.  It's very unlikely you can recover that disk's info at this point -- I don't believe XFS is as resilient as RFS is with regards to recreating file structure information from the headers interspersed on the disk.  Won't hurt to try ... but have realistic expectations.

 

I've probably seen more data lost in the last year or so on this forum by folks trying to convert from RFS to XFS than from actual disk failures.  You have to be VERY careful and VERY patient to do this error free ... to be certain you don't encounter the "user share copy" issue;  don't assign the wrong drive as parity (as you did); or any of several other potential "gotchas".    By far the SAFEST way to do the conversion is, one disk at a time, to copy ALL of the data from a disk to another location [either another array disk or a disk on another computer on the netwok];  then reformat the disk you just copied the data off of to XFS; and then copy the data back to it.  This approach also ensures parity is always valid, so there's no chance of miss-assignment.

 

[BobPhoenix]

I don't believe XFS is as resilient as RFS is with regards to recreating file structure information from the headers interspersed on the disk.

Actually I wonder if XFS would be just as good as ReiserFS if the XFS tool was better.  How much of the recovery is due to the tool or the file system?

[garycase]

I don't believe XFS is as resilient as RFS is with regards to recreating file structure information from the headers interspersed on the disk.

Actually I wonder if XFS would be just as good as ReiserFS if the XFS tool was better.  How much of the recovery is due to the tool or the file system?

 

Could be.  Without some details on the structure of the file system it's hard to say.  it's clear, however, that at the moment ReiserFSCK is appreciably better at recovery than the XFS check tool.

[BobPhoenix]

I don't believe XFS is as resilient as RFS is with regards to recreating file structure information from the headers interspersed on the disk.

Actually I wonder if XFS would be just as good as ReiserFS if the XFS tool was better.  How much of the recovery is due to the tool or the file system?

 

Could be.  Without some details on the structure of the file system it's hard to say.  it's clear, however, that at the moment ReiserFSCK is appreciably better at recovery than the XFS check tool.

Based on what I've read here on the forums - I would agree.