I am in the process of converting my old reiserfs disks to xfs. I checked parity prior to starting this process and all was good. I disabled VMs and Docker and made sure the mover was not scheduled. Since I had one drive already formatted in xfs (disk 6), I used unbalancer to move files off a reiserfs disk and onto the xfs disk 6. I repeated this process down the line, moving files off the next biggest reiserfs disk and onto the newly converted xfs disk.

 

The first couple disk conversions (disk 1 and 4) went as planned after formatting. Doing the same process with disk 2, it initially appeared to work fine and was formatted into xfs after clearing. I then began to move the files on disk 3 to disk 2, which completed as expected. When I shut down the array to format disk 3 to xfs and started the array up again, I noticed disk 2 was also coming up as unmountable. I did not format either disk 2 (for a second time) or 3 once I noticed this was an issue. I changed the format of disk 3 back to reiserfs so it would mount, but nothing was ever formatted.

 

I have read a few posts on xfs repair, but am checking for the best route forward. Is this an issue of the disk being too close to capacity? I also updated from Unraid 6.12.4 to 6.12.5 in between disks being moved (not during unbalancer running), but not sure if that is an issue.

 

Any help would be greatly appreciated.

 

tower-diagnostics-20231201-0850.zip

Edited December 1, 20232 yr by GMB44

Are you sure disk2 was formatted XFS? Doesn't appear to have a valid XFS filesystem, but on can check filesystem using the GUI, it won't hurt if it's not XFS.

I really appreciate the quick reply, as I am obviously concerned I just nuked a bunch of my data. I am running xfs repair -nv in maintenance mode now on disk 2 and will post results when done. So far, this is all they repair is saying:

Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!!

attempting to find secondary superblock..

 

I was able to see disk2 mounted as xfs originally, which is how I was able to move all the files from the reiserfs disk3 to disk2. Will I potentially be able to recover this data (it was moved and not copied) if the disk cannot be recognized as xfs?

 

Edited December 1, 20232 yr by GMB44

Make sure you are running it without -n, in case a good backup superblock is found.

So just to be clear, I should run it without any options in the check field? If so, I will cancel and restart without the -nv

-v is fine, though it usually doesn't make much of a difference. but don't use -n.

Here are the results from the xfs repair:

 

Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!!
attempting to find secondary superblock...found candidate secondary superblock... unable to verify superblock, continuing...

 

this repeated a few more times, followed by:

 

Sorry, could not find valid secondary superblock Exiting now.

 

As I said earlier, I was originally able to format disk 2 to xfs and mount it, otherwise I assume I wouldn't have been able to move the files from disk 3 to it. My concern is disk 3 was close to full capacity. Is it possible this was part of the issue and the moving of files somehow corrupted disk 2?

 

I am extremely grateful for any help I could continue to get on this. What is my next step, if any? I attached the diagnostics from maintenance mode and after running xfs repair, in case that is helpful.

tower-diagnostics-20231201-1638.zip

Edited December 1, 20232 yr by GMB44

If xfs_repair cannot fix the filesystem you will need to re-format the disk and restore the data from a backup, if there's no backup you can try a file recovery app, like UFS explorer.

Not the news I wanted to hear, but thanks for all your help. I have many of the files saved on an external hard drive, but no clone of the disk that could act as a true backup. I wouldn’t even know where to begin in terms of which specific files were on the disk in question.
 

If I were to try xfs recovery, which version do you think would best fit my scenario? Standard, access, raid, n raid?
 

https://www.ufsexplorer.com/products/

 

Thanks again for your help.
 

Standard is fine, you can try the free trial to see if it can find your data, to recover then only with the paid version.

Ok I have the disk migrated to a new box and am about to scan with UFS Explorer Standard Recovery. Do I want to scan the Linux partition or the entire disk?

Edited December 2, 20232 yr by GMB44

Apologies for the bump, but does anyone know if UFS Explorer is meant to be run on the Linux partition or the entire disk? Maybe it doesn’t matter, but I am hesitant to do anything that might hurt my chances of recovering data. 
 

As always, any help is greatly appreciated. 

Edited December 3, 20232 yr by GMB44

It is a while since I last ran UFS Explorer, but if I remember correctly it runs in read-only mode so both options should be safe.   

 

If it will run against just the partition that seems enough although it probably makes little difference as the partition is set to fill as much of the disk as possible,

Thankfully UFS Explorer managed to find almost all the files on the corrupted disk. I am in the process of moving them onto a spare hard drive.

 

First, thank you both for your patience and help.

 

Second, what should be my next step once all the files are on a spare NTFS drive that I can mount on unraid? I already have disk 3 emptied from a few days ago and can format it to XFS. I could potentially start moving files onto that. I am not sure what to do with disk 2 (the corrupted disk) or how to ensure parity remains intact. 

4 hours ago, GMB44 said:

I am not sure what to do with disk 2 (the corrupted disk) or how to ensure parity remains intact.

You can just reformat once the data is recovered. Parity should remain in sync assuming the data recovery was done without mounting the disk, but you can run a parity check after to confirm.

Just wanted to say thanks again for the help. It appears everything has successfully transferred/formatted. I will run a parity check and should hopefully be back in business.

Sadly the parity check returned millions of errors after only running though roughly 1% of the array. It is still running, but I am doing so without auto correcting. I am not sure where I went wrong in rebuilding everything.

 

Once UFS Explorer found the missing files (using a different Windows machine), I moved them onto a spare drive (again, all done on a Windows machine separate from Unraid). I returned to my Unraid machine and formatted the unformatted disk to XFS. Then I mounted the spare drive using unassigned devices and moved the files from the spare drive to the newly formatted XFS drive.

 

I also had one more ReiserFS drive to convert to XFS. I used midnight commander to move the files on that disk to a couple different disks until it was empty. Then I converted that to XFS. It is still empty, but all disks show up as XFS when mounted.

 

I am sorry this continues to drag on. Should I continue running the non-correcting parity check? I attached diagnostics, but I am not sure if they are any help while parity check is still running.

tower-diagnostics-20231205-2316.zip

Edited December 6, 20232 yr by GMB44
Added diagnostics

5 hours ago, GMB44 said:

Once UFS Explorer found the missing files (using a different Windows machine), I moved them onto a spare drive (again, all done on a Windows machine separate from Unraid). I returned to my Unraid machine and formatted the unformatted disk to XFS. Then I mounted the spare drive using unassigned devices and moved the files from the spare drive to the newly formatted XFS drive.

If I understood correctly then all the sync errors are expected, just correct them.