Skip to content
View in the app

A better way to browse. Learn more.

Unraid

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Really stupid mistake - Help please

Featured Replies

Background - I have x3 10tb one of which was parity other two were data and x3 8tb. All of the 8tb drives along with one of the 10tb drives were empty and not being written to by unraid.

Long story short since on of the 10 tb drives were not being used I figured it would be a good idea to remove the drive from my array and have it as a warm spare for my parity drive. This is where the F up started.

I jumped ahead and hit the new config, and elected to not preserve anything, as I through I knew the drive layout (HUGE mistake). I wiped the config, re allocated the drives in the order I thought I remembered and hit parity sync.

Immediately I noticed the one 10 tb drive that I though had my data had an unreadable file system, and I immediately knew I got the parity and the data drive around the wrong way and just wiped my data drive.

Now the question is, since I have my "old configuration's parity drive" still intact and I essentially have just gone through a dead drive situation, how can I convince the configuration I have is valid so I can re assign the drives in the correct order and perform a rebuilt of the one drive I wiped?

No, this is the 2nd F up, I didn't backup my config that I know of. It's connected to the unraid online which I though backed up my config, but upon looking can't see that being the case.

Any help would be really appreciated.

Thank you

Edited by bennymundz
Clarification

  • Community Expert

You can try this, but it will only work if parity is still valid:

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

-Check all assignments and assign all the disks as they were before the change

-IMPORTANT - Check both "parity is already valid" and "maintenance mode" and start the array (note that the GUI will still show that data on parity disk(s) will be overwritten, this is normal as it doesn't account for the checkbox, but it won't be as long as it's checked)

-Stop array

-Unassign the disk you want to rebuild

-Start array (in normal mode now), and post the diagnostics

  • Author

Ill give it a go now

  • Author

Outcome. It now detects as XFS but is not emulating the contents of the drive.

Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
Metadata CRC error detected at 0x49620d, xfs_rmapbt block 0x200000040/0x1000
btree block 4/12 is suspect, error -74
invalid start block 1925355057 in record 63 of rmap btree block 4/12
out-of-order rmap btree record 75 (2644636 8611223038 0 8) block 4/12
invalid start block 4274348048 in record 83 of rmap btree block 4/12
invalid flags in record 84 of rmap btree block 4/12
invalid start block 1764285104 in record 85 of rmap btree block 4/12
invalid length 536870968 in record 87 of rmap btree block 4/12
invalid flags in record 88 of rmap btree block 4/12
invalid flags in record 89 of rmap btree block 4/12
invalid start block 3426770109 in record 90 of rmap btree block 4/12
invalid owner in rmap btree record 91 (40694836542534 4) block 4/12
invalid start block 4292289813 in record 92 of rmap btree block 4/12
invalid start block 405330670 in record 93 of rmap btree block 4/12
invalid flags in record 94 of rmap btree block 4/12
invalid flags in record 95 of rmap btree block 4/12
invalid flags in record 96 of rmap btree block 4/12
invalid start block 2681123853 in record 97 of rmap btree block 4/12
invalid flags in record 105 of rmap btree block 4/12
invalid length 680760619 in record 106 of rmap btree block 4/12
invalid flags in record 125 of rmap btree block 4/12
invalid flags in record 126 of rmap btree block 4/12
invalid flags in record 127 of rmap btree block 4/12
invalid flags in record 128 of rmap btree block 4/12
invalid length 1761607721 in record 129 of rmap btree block 4/12
invalid flags in record 130 of rmap btree block 4/12
invalid start block 2455921752 in record 131 of rmap btree block 4/12
invalid flags in record 132 of rmap btree block 4/12
invalid flags in record 133 of rmap btree block 4/12
invalid owner in rmap btree record 134 (867234299387003825 1) block 4/12
invalid start block 4292289056 in record 136 of rmap btree block 4/12
invalid flags in record 137 of rmap btree block 4/12
invalid flags in record 138 of rmap btree block 4/12
invalid flags in record 139 of rmap btree block 4/12
invalid flags in record 145 of rmap btree block 4/12
invalid owner in rmap btree record 148 (5585902498079523734 52) block 4/12
invalid start block 4292288719 in record 149 of rmap btree block 4/12
invalid owner in rmap btree record 160 (140750440317889 1) block 4/12
        - 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
entry "                                                                                          ,gdia�" in shortform directory 128 references invalid inode 562949953488228
entry contains illegal character in shortform dir 128
would have junked entry ",gdia�" in directory inode 128
entry "                                                                                                                       0Photos" in shortform directory 128 references invalid inode 0
entry #1 extends past end of dir in shortform dir 128, would junk 5 entries
would have corrected entry count in directory 128 from 6 to 1
would have corrected i8 count in directory 128 from 4 to 0
would have corrected directory 128 size from 159 to 118
directory 128 offsets too high
would have corrected entry offsets in directory 128
would have corrected root directory 128 .. entry from 83910861 to 128
xfs_repair: dir2.c:1551: process_dir2: Assertion `(ino != mp->m_sb.sb_rootino && ino != *parent) || (ino == mp->m_sb.sb_metadirino && (ino == *parent || need_metadir_dotdot == 1)) || (ino == mp->m_sb.sb_rootino && (ino == *parent || need_root_dotdot == 1))' failed
  • Community Expert

Did you check filesystem from the webUI or the command line? More than one way to get the command wrong, webUI will get it right.

  • Author

WebUI

The process i used

On the main page > clicked disk number (Disk1 in my instance) > Scrolled down to Check Filesystem Status section > Pressed check and let it run.

Edited by bennymundz

  • Community Expert

Did it give you the FIX button?

  • Author

No it did not.

  • Community Expert

Click the FIX button.

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.

Guest
Reply to this topic...

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.