Hi all,

Back with another weird issue.

Long story short, I have the error in the title on two drives following a power outage during parity check, wondering how to pull data off them before reformatting and re-adding to array.

Details below:

I recently added 3x new 26 TB HDDs to my array.

One replaced a failed 14 TB drive (removed failed drive, added new (Disk 7) rebuilt disk)

One replaced the existing 22 TB Parity (added 26 TB Parity 2, recalculated, removed Parity 1)

The final 26 TB one, along with the 22TB previously-Parity 1 drive were added as new disks, Disk 15 and Disk 14 respectively.

After the final two disks were added parity, they were cleared as normal, this took a couple of days.

I didn't monitor the state after this but there was a power outage that resulted in an unsafe shutdown.

On restart, the array was recalculating parity, as expected.

During the next couple of days, there was another power outage.

When the array came back up, it mounted, but the two new disks now show up with the FS attribute showing as "auto" and the error:

Unmountable: unsupported or no file system

I have looked through other threads and performed the following steps.

Firstly, there is no Check Filesystem Status section in these disks settings, probably because they're not even identified as xfs, so I can't "click the Check button" as is referenced in other threads. See below Disk 14 and Disk 15 Settings. I've also added a Disk 13 Settings screenshot of a good disk that does show the section and button.

I instead manually ran xfs_repair -v /dev/md14p1 and xfs_repair -v /dev/md15p1 on the disks.

This immediately detects a bad primary superblock and then takes over a day on each drive (I guess it's scanning the whole disk?) and fails to find a secondary superblock.

Phase 1 - find and verify superblock...
bad primary superblock - bad magic number !!!
attempting to find secondary superblock...
................................................ 
Sorry, could not find valid secondary superblock
Exiting now.

Is there a next step to try and repair the filesystem on these disks and attempt to view what files may have been placed there in the day or two they were live before this problem?

Ideally I'd just want to access and pull those files off, then I assume reformat these two again?

I have since solved my power issue - I have a UPS that is now 3-4 years old and Unraid is configured to shut down when it reaches 10 minutes of battery run-time left. The UPS used to last about 2 hours, however, due to battery degradation, now after an hour on no power, it quickly drops from reporting ~45 mins runtime left to 2 mins, then loses power within the minute.

I have now recalibrated it and set Unraid to shut down after 20 minutes of a continued power outage event to avoid this same problem.

I've also attached diagnostics.

define-diagnostics-20251222-1021.zip

Edited December 22, 2025Dec 22 by fredskis

7 hours ago, fredskis said:

After the final two disks were added parity, they were cleared as normal, this took a couple of days.

I didn't monitor the state after this but there was a power outage that resulted in an unsafe shutdown.

On restart, the array was recalculating parity, as expected.

Were the disks ever formatted after the clear? The issues you see suggest they were not.

On 12/22/2025 at 6:24 PM, JorgeB said:

Were the disks ever formatted after the clear? The issues you see suggest they were not.

That's the question I'm asking - if it's possible to determine.

Between the clear supposedly finishing and the first power event that triggered the parity check (a day or so) I didn't get a chance to manually validate.

As I understand it, if the format never completed then the behaviour explains itself and there is no useful data on those disks anyway and my solution would be to format again.

However, I don't know if there's a chance for the format to have happened and then the power event caused something strange to happen or to revert to a previous config while there having been some data written to those disks that I now can't identify...

8 hours ago, fredskis said:

That's the question I'm asking - if it's possible to determine.

Assuming that if they were formatted, they were formatted XFS, you can look for the signature:

dd if=/dev/sdX bs=16M status=progress 2>/dev/null | hexdump -C | grep 'XFSB'

Replace X with the correct disk letter; if they have a signature, it should output something after a few seconds, a couple of minutes tops. You can cancel at any time with CTRL + C

17 minutes ago, JorgeB said:

Assuming that if they were formatted, they were formatted XFS, you can look for the signature:

dd if=/dev/sdX bs=16M status=progress 2>/dev/null | hexdump -C | grep 'XFSB'

Replace X with the correct disk letter; if they have a signature, it should output something after a few seconds, a couple of minutes tops. You can cancel at any time with CTRL + C

Thanks for that.

Been about 10 minutes now and no output from either.

Guessing they weren't formatted then.

4 hours later, still no output from those commands.

Oh well, here goes a format 😁

🤞🏽

Edit:

Interestingly, format completed very quickly - I thought it would constitute a lengthy clean process as well - I guess it successfully cleaned during the original format operation?

Any reason to be concerned that the disks list ~1.9% of data already "Used"?

421 GB for the 22 TB disk and 498 GB for the 26 TB disk

I had a quick look with lsblk and didn't notice any bonus partitions nor do I see files when trying to browse the mount points

Edited December 28, 2025Dec 28 by fredskis
Newly discovered information!

That is standard. It is the space used to create the file system structure that will later be used to hold files.

1 minute ago, itimpi said:

That is standard. It is the space used to create the file system structure that will later be used to hold files.

Great - thank you @itimpi for confirming that 🙂

I think this is back to working now then!

Thanks again @JorgeB