I have restarted my unraid after moving states, and during this move i had removed the drives from the server and put them in extremely well packed bubble wraps in a secure container.

Now, after a few months i have finally setup my server rack and after installing the hdd's into my 24 supermicro bay, unraid has come back online but two of the drives show "Unmountable: Wrong or no Filesystem" and "Unmountable: Unsupported or Wrong filesystem"

These drives were working before. They were a part of the unraid system, but now i get these. Diagnostic attached with this post.

 

tower-diagnostics-20221218-2345.zip

Edited December 22, 20223 yr by Socrates

Assuming disk13 was also xfs, stop the array, click on disk13 and set the filesystem to xfs, start array and post new diags.

6 hours ago, JorgeB said:

Assuming disk13 was also xfs, stop the array, click on disk13 and set the filesystem to xfs, start array and post new diags.

 

Thanks for looking into this.

I've performed the operation you recommended on both the disks, made them xfs from auto and started the array again, and still it shows the same result Unmountable: Wrong or no Filesystem" and "Unmountable: Unsupported or Wrong filesystem"

 

New logs from diags attached.

tower-diagnostics-20221219-1101.zip

Check filesystem on disk12, are you sure disk13 had a filesystem before? No valid filesystem is being detected, and even forcing xfs doesn't work meaning it's not xfs, or it's not there any more.

6 hours ago, JorgeB said:

Check filesystem on disk12, are you sure disk13 had a filesystem before? No valid filesystem is being detected, and even forcing xfs doesn't work meaning it's not xfs, or it's not there any more.

 

I have initiated the check on Disk 12, its been running for a few hours, will report back tomorrow or when it completes.

 

That's not a good sign...

Its still running and nothing has changed. what does it mean? Do u think its better for me to format these drives using xfs and then rebuild it with the 2 parity drives i have?

Parity can't help with filesystem problems, if no valid superblock was found so far unlikely that one will be, this could be a xfs_repair problem or the filesystem is corrupt beyond repair, in any case best bet assuming no backups are available would be to use a file recovery util like UFS explorer.

Wait i am sorry i am failing to understand. you are saying i cannot treat these two drives as new drives and recover data from parity? I do have two parity drives in healthy state. WHy cant i treat them as two failed drives and recover the data from parity?

Before any recover action, does disk assignment have change after moving ? Since they are same 10TB size and all other member disk are HGST.

Edited December 20, 20223 yr by Vr2Io

49 minutes ago, Socrates said:

are saying i cannot treat these two drives as new drives and recover data from parity?

Yes, because

 

7 hours ago, JorgeB said:

Parity can't help with filesystem problems

 

So here is the final result.

FS: xfs

Executing file system check: /sbin/xfs_repair -n /dev/sdi1 2>&1
Phase 1 - find and verify superblock...
Phase 2 - using internal log
- zero log...
ALERT: The filesystem has valuable metadata changes in a log which is being
ignored because the -n option was used. Expect spurious inconsistencies
which may be resolved by first mounting the filesystem to replay the log.
- scan filesystem freespace and inode maps...
sb_fdblocks 1657832310, counted 1659752643
- found root inode chunk
Phase 3 - for each AG...
- scan (but don't clear) agi unlinked lists...
- process known inodes and perform inode discovery...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
- agno = 4
- agno = 5
- agno = 6
- agno = 7
- process newly discovered inodes...
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- check for inodes claiming duplicate blocks...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
- agno = 4
- agno = 5
- agno = 6
- agno = 7
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
- traversing filesystem ...
- traversal finished ...
- moving disconnected inodes to lost+found ...
Phase 7 - verify link counts...
No modify flag set, skipping filesystem flush and exiting.

File system corruption detected!
RUN WITH CORRECT FLAG
DONE

 

You need to run without the -n (no modify) flag or nothing is changed, and if it asks for it add the -L flag

Did you unassign the disk? Which disk is this one?

1 hour ago, JorgeB said:

Yes, because

 

 

 

Filesystem is not hardware curroption, right? Can't i format the drive, format it with XFS filesystem, this way it becomes a new drive, and then plug it in and resover using the 2 parities I have?

Rebuilding from parity won't help with, please see my previous question.

17 hours ago, Socrates said:

Filesystem is not hardware curroption, right? Can't i format the drive, format it with XFS filesystem, this way it becomes a new drive, and then plug it in and resover using the 2 parities I have?

No because file system corruption happens at a different level to hardware failures and is not visible to parity.   If a disk is showing file system corruption before starting a rebuild it would just show the same file system corruption after the rebuild.

That last UD xfs_repair log suggests the fs is fixable, which is strange since when the disk was in the array it didn't look fixable.

On 12/20/2022 at 1:27 PM, JorgeB said:

Did you unassign the disk? Which disk is this one?

 

Steps i undertook

1. Stopped the array.

2. Started the Array in Maintenance mode.

3. Clicked on Disk 12 and then ran the check. No i did not unassign this disk.

 

Do u want to unassign this and then run the xfs check with no -n switch?

18 hours ago, JorgeB said:

That last UD xfs_repair log suggests the fs is fixable, which is strange since when the disk was in the array it didn't look fixable.

Do u want me to go ahead with the fix? Please could u post the steps for fixing this? Or do u want to first run the xfs check again after converting the disk to unassign mode?

How do i convert Disk 12 to unassigned disk? all i can see is the option of no device in the drop down.

The xfs_repair log you've posted is from the UD plugin, not the Unraid GUI, something is missing here.

 

Post new diags. 

 

I have started the array to pull the diag report now parity is being synced, says data rebuild in progress. Diag logs attached below.

tower-diagnostics-20221222-1027.zip

14 minutes ago, Socrates said:

says data rebuild in progress

Because you had unassigned disk13 before, contrary to what you've said.

3 hours ago, JorgeB said:

Because you had unassigned disk13 before, contrary to what you've said.

I had Disk13 as unassigned, but disk12 was not. I just brought all the disk back to run the diagnostics again.. and its running parity now.

What should be my next steps? wait for parity rebuild to complete, and then run diag?