Yesterday at 03:02 PM1 day 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 22 hours ago22 hr by HAMANY
11 hours ago11 hr Community Expert Post the xfs_Reapir output from the emulated disk7; also run it on disk2, since the syslog is showing issues with that filesystem.
10 hours ago10 hr Author 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?
10 hours ago10 hr Community Expert Filesystem check must be in maintenance mode. Don't change any assignments for now.
10 hours ago10 hr Author 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 10 hours ago10 hr by HAMANY
9 hours ago9 hr Author disk 2 - L.txt disk 7 - L.txtDone - L for both. Logs are attached.What should be done next?Thank you. Edited 9 hours ago9 hr by HAMANY
6 hours ago6 hr Community Expert Start array in normal mode now (without changing the disk assignments) and post new diags.
6 hours ago6 hr Author 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
6 hours ago6 hr Community Expert Emulated disk 1 also has issues, I thought that one was mounting before. You also need to check fileystem on that one.
6 hours ago6 hr Author 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 5 hours ago5 hr by HAMANY
5 hours ago5 hr Community Expert Disk is emulated, but it's not mounting. Unassigning the disabled disk should have no effect, but just check the filesystem.
5 hours ago5 hr Community Expert 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.
4 hours ago4 hr Author 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 1Disk 1 xfs_repair statusPhase 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.
4 hours ago4 hr Community Expert 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.
4 hours ago4 hr Author 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?
4 hours ago4 hr Community Expert 43 minutes ago, HAMANY said:No modify flag setRun without -n , and again if it asks for -L use it
4 hours ago4 hr Author 2 minutes ago, JorgeB said:Run without -n , and again if it asks for -L use itDone, it didn't ask for -LCan I run the array in normal mode now?Disk 1 xfs_repair statusPhase 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 3 hours ago3 hr by HAMANY
2 hours ago2 hr Community Expert 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.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.