May 12, 20179 yr hi folks. Long time user of Unraid. Going on strong since Jan-2011! Never had major issues i couldn't resolve, but ran into a nasty one i can't wrap my head around. Looking for some help, as i'm pretty stressed out right now thinking i may have lost data. hate this feeling. situation: - parity drive had some i/o errors, thinking it was the cable, moved a few cables around and rebuilt with a new parity drive. NO ISSUES. - rebooted this morning, after a successful parity rebuilt and check; one of the data drive, drive #3 shows unmountable (XFS file system). - CLI: "xfs_repair -v -L /dev/sdd" to see if that would resolve the issue. ended up with: Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock... - this "......" goes one for 10+ mins with no avail. I ended up powering down the server and replacing the hard data drive with the another drive. - new drive shows up as needing formatting (not a surprise) but also as unmountable (surprise). - i end up doing both... UGH. should i have? Now i'm afraid that i reformatted the drive to blank and rebuilt a party around blank. I can't tell, because there's 6 more hours of rebuilt left... but the formatting is done. - i guess the only saving grace i have right now is that i have the old data drive i pulled that has all my data (i care about saving the data); but is xfs unmountable. folks----> where did i go wrong? did i go wrong? and how do i get myself out of this very stressful situation? Can i mount the old data drive external to the array and copy over the data to the formatted disk 3 or should i mount it via Mac OSX/Win10 and move from there? Thoughts... help.... standing by to listen and pleading for assist.
May 12, 20179 yr Community Expert Assuming drive #3 means disk3, It should be: xfs_repair -v /dev/md3 -L only if needed Edited May 12, 20179 yr by johnnie.black
May 12, 20179 yr Author 4 minutes ago, johnnie.black said: Assuming drive #3 means disk3, It should be: xfs_repair -v /dev/md3 -L only if needed Ok. Syntax error could explain why I had a bunch of dots. Thank you. Im guessing I shouldn't stop the rebuild? Is this xfs repair something I can do after the rebuild is done or should I stop the process. Is my rebuild rebuilding a blank drive? The free space during the rebuild shows nearly the entire size of the drive and I'm about 20% through.
May 12, 20179 yr Community Expert Your are rebuilding and empty drive, you need to run xfs_repair on the old one, outside the array, or putting it back in the array after doing a new config, don't rebuild using the old drive. Edited May 12, 20179 yr by johnnie.black
May 12, 20179 yr Community Expert To repair the drive outside the array, use: xfs_repair -v /dev/sdX1 Note the 1 in the end.
May 12, 20179 yr Author johnnie.black - thank you for the quick replies, really making me feel better. to make sure i understand you correctly and not mess this up again.. baby steps to make sure i'm crystal clear. 1. do (or don't) stop the current rebuild on the new data drive? looks like it's not accomplishing anything... soo... if i stop it now, will that be OK? 2. do i just mount the drive on a spare sata port and boot normally? or should i use "unassigned drives", etc to run this CLI? I'm thinking the plugin shouldn't be necessary. (https://lime-technology.com/wiki/index.php/Check_Disk_Filesystems#Preparing_to_run_xfs_repair) 3. assuming i get the xfs repaired, do i think just use MC to move the files to the new data drive or do i replace the drive 3 with the old drive? or is this dependent on whether or not i stopped the parity rebuilt in step 1? thank you so much in advance! Edited May 12, 20179 yr by pkh106
May 12, 20179 yr Community Expert 1. If you prefer to keep using the old disk on the array stop the rebuild and do a new config, if not let it finish and then copy the data from the old disk. 2. it's easier using the UD plugin, especially if you want to copy the data to the array. 3. dependent on 1
May 12, 20179 yr Author johnnie.black - thank you. i'm interested in stopping the blank rebuild early. so. i'm going to stop the rebuild. reattach the old data drive. telnet/ssh into my CLI run this for drive3 xfs_repair -v /dev/md3 after that, do i press "new config" at that point? thank you for walking me through this.
May 12, 20179 yr Community Expert cancel the rebuild stop the array and reattach old disk3 take a screenshot of the array just in case tools -> new config -> select "retain all" assign old disk3. start the array in maintenance mode, cancel the parity sync. run xfs_repair on disk3 (md3) start the array in normal mode, hopefully disk3 now mounts, let the parity sync finish.
May 12, 20179 yr Author canceled the rebuild stopped the array and reattached the old disk3 screenshot made a "new config" all; hit apply, done assigned the old disk3 started the array in maintenance mode, no parity sync started, but all disks are green circles, party is a orange triangle. no FS/size/used/free is read! (is this because it's maintenance mode?) went to CLI and ran: root@Tower:~# xfs_repair -v /dev/md3 Phase 1 - find and verify superblock... - block cache size set to 4575984 entries Phase 2 - using internal log - zero log... zero_log: head block 1169372 tail block 1169368 ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this. ... goes back to command prompt. not sure what to do from here. Edited May 12, 20179 yr by pkh106
May 12, 20179 yr Author so... this appears to be where i was earlier, prior to swapping out the drive... except for the fact that my parity drive was a green ball vice orange triangle Edited May 12, 20179 yr by pkh106
May 12, 20179 yr Author big sigh of relief... that appeared to work! parity is rebuilding now, disk 3 appears to look correct again. should i be concerned about this statement "Check for a lost+found folder on this drive, which may contain fragments of the unrecoverable files." what showed up when i used -L root@Tower:~# xfs_repair -v -L /dev/md3 Phase 1 - find and verify superblock... - block cache size set to 4575984 entries Phase 2 - using internal log - zero log... zero_log: head block 1169372 tail block 1169368 ALERT: The filesystem has valuable metadata changes in a log which is being destroyed because the -L option was used. - scan filesystem freespace and inode maps... sb_fdblocks 176911372, counted 176919564 - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 data fork in ino 134959464 claims free block 8434970 - 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 = 7 - agno = 6 Phase 5 - rebuild AG headers and trees... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... XFS_REPAIR Summary Fri May 12 09:27:00 2017 Phase Start End Duration Phase 1: 05/12 09:26:00 05/12 09:26:01 1 second Phase 2: 05/12 09:26:01 05/12 09:26:51 50 seconds Phase 3: 05/12 09:26:51 05/12 09:26:55 4 seconds Phase 4: 05/12 09:26:55 05/12 09:26:55 Phase 5: 05/12 09:26:55 05/12 09:26:55 Phase 6: 05/12 09:26:55 05/12 09:26:59 4 seconds Phase 7: 05/12 09:26:59 05/12 09:26:59 Total run time: 59 seconds done
May 12, 20179 yr Community Expert 3 minutes ago, pkh106 said: should i be concerned about this statement "Check for a lost+found folder on this drive, which may contain fragments of the unrecoverable files." Just check if that folder exists and if yes any files there may be corrupt.
May 12, 20179 yr Author i think i'm good! thank you for all your help. going to mark this as closed in a few hours once parity has completed successfully.
May 13, 20179 yr Author appears to be all good now, back and running again. big thanks to jonnie.black for helping me through.
Archived
This topic is now archived and is closed to further replies.