Hi all. I would appreciate your help.

2 of my drives are disabled (Disk 1, and Disk 7), and I've 2 parity drives.

Disk 1 was disabled for sometime, and the data was emulated. But when disk 7 got disabled, the content of disk 7 where disappeared, although the status is (Disabled, content emulated). When I tried to browse disk 7, I got "Invalid path" or something close to that. Could be a file system corruption.

• I've unassigned disk 1 and tried to assign a larger drive (18TB), then discovered that it's not possible, as my parity is 8TB. The current status is "unassigned".

• Since unassigned and disconnect disk 1, I have only started the array in "Maintenance mode" once only. I didn't start it in normal mode.

• After starting the array in "Maintenance mode", I tried to "Check Filesystem Status" of disk 7 with and without -n. The repair button didn't appear. Didn't do anything else.

Q: What is the best way to proceed with minimal data loss? I'm moving my data to the new Unraid server, and will do a new config for this server. So rebuilding the drives in not really important unless necessary.

Thank you.

tower-diagnostics-20260704-0423.zip ST8000VN004-3CP101_WWZ2J8M4-20260704-0245 disk1 (sdi) - DISK_DSBL.txt

Edited Sunday at 08:22 PM1 day by HAMANY

Post the xfs_Reapir output from the emulated disk7; also run it on disk2, since the syslog is showing issues with that filesystem.

14 minutes ago, JorgeB said:

Post the xfs_Reapir output from the emulated disk7; also run it on disk2, since the syslog is showing issues with that filesystem.

Thank you for your response JorgeB.

Should I start the array in normal mode first? Should I keep disk 1 as unassigned?

Filesystem check must be in maintenance mode. Don't change any assignments for now.

6 minutes ago, JorgeB said:

Filesystem check must be in maintenance mode. Don't change any assignments for now.

Please find attached both xfs_repair reports.

disk 2.txt disk 7.txt

Edited yesterday at 08:49 AM1 day by HAMANY

Run again for both without -n, and if it asks for -L use it.

disk 2 - L.txt disk 7 - L.txt

Done - L for both. Logs are attached.

What should be done next?

Thank you.

Edited yesterday at 10:17 AM1 day by HAMANY

Start array in normal mode now (without changing the disk assignments) and post new diags.

8 minutes ago, JorgeB said:

Start array in normal mode now (without changing the disk assignments) and post new diags.

Attached, thanks.

tower-diagnostics-20260706-1550.zip

Emulated disk 1 also has issues, I thought that one was mounting before. You also need to check fileystem on that one.

22 minutes ago, JorgeB said:

Emulated disk 1 also has issues, I thought that one was mounting before. You also need to check fileystem on that one.

It was emulating the last time on normal mode. Since I unassigned it, this is the first time I started the array in normal mode.

Edited yesterday at 01:30 PM1 day by HAMANY

Disk is emulated, but it's not mounting. Unassigning the disabled disk should have no effect, but just check the filesystem.

Note that repair has created lost+found on the 2 repaired disk. Might also happen when you repair disk1.

Repair puts folders and files that it can't figure out in lost+found. Since it is a top level folder on those disks, it is also a user share.

Linux 'file' command might be able to tell you what kind of data is in a particular file so you can try to open it in an appropriate application to see if you know what it is.

53 minutes ago, JorgeB said:

Disk is emulated, but it's not mounting. Unassigning the disabled disk should have no effect, but just check the filesystem.

Hi JorgeB, this is the xfs_repair status of disk 1

Disk 1 xfs_repair status

Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
Metadata CRC error detected at 0x43e660, xfs_agf block 0xfffffff1/0x200
agf has bad CRC for ag 2
Metadata CRC error detected at 0x469f20, xfs_agi block 0xfffffff2/0x200
agi has bad CRC for ag 2
Metadata CRC error detected at 0x469f20, xfs_agi block 0x2ffffffd2/0x200
agi has bad CRC for ag 6
Metadata CRC error detected at 0x43e660, xfs_agf block 0x17fffffe9/0x200
agf has bad CRC for ag 3
Metadata CRC error detected at 0x469f20, xfs_agi block 0x17fffffea/0x200
agi has bad CRC for ag 3
agi_freecount 125, counted 55 in ag 6
agi_freecount 125, counted 55 in ag 6 finobt
agf_freeblks 30657948, counted 30657805 in ag 2
agi_freecount 201, counted 44 in ag 2
agi_freecount 201, counted 44 in ag 2 finobt
agf_freeblks 47320525, counted 47320427 in ag 3
agi_freecount 4, counted 56 in ag 3
agi_freecount 4, counted 56 in ag 3 finobt
        - 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 = 3
        - agno = 6
        - agno = 4
        - agno = 1
        - agno = 7
        - agno = 5
        - agno = 2
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.

18 minutes ago, trurl said:

Note that repair has created lost+found on the 2 repaired disk. Might also happen when you repair disk1.

Repair puts folders and files that it can't figure out in lost+found. Since it is a top level folder on those disks, it is also a user share.

Linux 'file' command might be able to tell you what kind of data is in a particular file so you can try to open it in an appropriate application to see if you know what it is.

You're right, I can browse my files now in disk 7 and noticed the lost+found folder. Which is a good sign.

If you examine lost+found, you will find it has random folder and file names.

34 minutes ago, trurl said:

Linux 'file' command might be able to tell you what kind of data is in a particular file so you can try to open it in an appropriate application to see if you know what it is.

Often if there is a lot of lost+found, it may be easier to recover that data from backups.

16 minutes ago, trurl said:

If you examine lost+found, you will find it has random folder and file names.

Often if there is a lot of lost+found, it may be easier to recover that data from backups.

Noted, will check that.

Should I run the repair on disk 1 without -n and with -L when requested?

43 minutes ago, HAMANY said:

No modify flag set

Run without -n , and again if it asks for -L use it

2 minutes ago, JorgeB said:

Run without -n , and again if it asks for -L use it

Done, it didn't ask for -L

Can I run the array in normal mode now?

Disk 1 xfs_repair status

Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
Metadata CRC error detected at 0x469f20, xfs_agi block 0x2ffffffd2/0x200
agi has bad CRC for ag 6
Metadata CRC error detected at 0x43e660, xfs_agf block 0xfffffff1/0x200
agf has bad CRC for ag 2
Metadata CRC error detected at 0x43e660, xfs_agf block 0x17fffffe9/0x200
agf has bad CRC for ag 3
Metadata CRC error detected at 0x469f20, xfs_agi block 0xfffffff2/0x200
agi has bad CRC for ag 2
Metadata CRC error detected at 0x469f20, xfs_agi block 0x17fffffea/0x200
agi has bad CRC for ag 3
agi_freecount 125, counted 55 in ag 6
agi_freecount 125, counted 55 in ag 6 finobt
agf_freeblks 30657948, counted 30657805 in ag 2
agi_freecount 201, counted 44 in ag 2
agi_freecount 201, counted 44 in ag 2 finobt
agf_freeblks 47320525, counted 47320427 in ag 3
agi_freecount 4, counted 56 in ag 3
agi_freecount 4, counted 56 in ag 3 finobt
        - found root inode chunk
Phase 3 - for each AG...
        - scan and 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 = 5
        - agno = 1
        - agno = 3
        - agno = 4
        - agno = 6
        - agno = 7
        - agno = 2
Phase 5 - rebuild AG headers and trees...
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - traversing filesystem ...
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
done

Edited yesterday at 03:21 PM1 day by HAMANY

1 hour ago, HAMANY said:

Can I run the array in normal mode now?

Yep, and if all disks mount now, check their contents; also post new diags.

Thank you @JorgeB @trurl for your support.

The content of all drives are viewable, the lost+found are minimal, any lost content can be restored again. The used space looks almost similar, around 1TB less.

Unrelated question: Is it possible to add an (xfs) drive with existing content to an array of the same file system (xfs) without losing the content of the new drive? I'm aware that the parity has to be rebuild again.

I'm thinking about copying the data to a local xfs drive instead of transferring them through the network.

tower-diagnostics-20260706-1953.zip

9 hours ago, HAMANY said:

Is it possible to add an (xfs) drive with existing content to an array of the same file system (xfs) without losing the content of the new drive?

Yep, you need to do a new config and then resync parity

-Tools -> New Config -> Preserve current assignments: All -> Apply

Then assign the new data disk and start the array