Bill A Posted February 12, 2020 Share Posted February 12, 2020 (edited) I lost my unraid config and had to restart from scratch... I have 2 8tb drives in my array, one for parity and one for data. I added one to the disk 1 slot and one more disk as disk 2, I started the array and thought I clicked on disk 1 and verified I could access the data I thought was on the 8tb data disk, but must have clicked on disk 2... I stopped the array and added the other disks to the array and added the other 8tb disk to the parity... I started the array and noticed right away it showed it was rebuilding the parity, and disk 1 had an unmountable file system. I stopped the parity creation, and stopped the array within maybe 10 seconds of starting the array.... I pulled the 8tb drive from the parity and moved it back down as a data disk and rebooted the server... now both 8tb drives show as "unmountable no file system"... Is my 8tb data drive fried? If I move the correct parity drive back to the parity slot will it rebuild the 8tb data disk (yes it might be missing some recent data but not multiple TB of data)? Edited February 13, 2020 by Bill A Quote Link to comment
JorgeB Posted February 12, 2020 Share Posted February 12, 2020 Please post the diagnostics: Tools -> Diagnostics Quote Link to comment
Bill A Posted February 13, 2020 Author Share Posted February 13, 2020 18 hours ago, johnnie.black said: Please post the diagnostics: Tools -> Diagnostics here is the diags. in an effort to try to recover, or at least see if it might be possible, I ran xfs repair with the "-n" option. Disk 1 had about 95,000 reads and returned Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... finobt ir_freecount/free mismatch, inode chunk 0/46373760, freecount 63 nfree 61 sb_ifree 326, counted 322 sb_fdblocks 852809396, counted 845469364 - 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 would have corrected i8 count in directory 96 from 4 to 2 would have corrected directory 96 size from 141 to 122 imap claims in-use inode 79531821 is free, would correct imap - 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 = 1 - agno = 0 - agno = 2 - agno = 6 would have corrected i8 count in directory 96 from 4 to 2 - agno = 4 - agno = 5 - agno = 7 - agno = 3 would have corrected directory 96 size from 141 to 122 No modify flag set, skipping phase 5 Inode allocation btrees are too corrupted, skipping phases 6 and 7 No modify flag set, skipping filesystem flush and exiting. Disk 9 had over 15,000,000 reads and returned (there were lines of hundreds of dots also that I cleaned out of this post) Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock... .....found candidate secondary superblock... unable to verify superblock, continuing... .found candidate secondary superblock... unable to verify superblock, continuing... .found candidate secondary superblock... unable to verify superblock, continuing... ......... unable to verify superblock, continuing... ........ unable to verify superblock, continuing... .......... unable to verify superblock, continuing... ......... exiting now. tower-diagnostics-20200212-2006.zip Quote Link to comment
JorgeB Posted February 13, 2020 Share Posted February 13, 2020 By the looks of it disk1 was likely the correct data disk, but fs is corrupted, running xfs_repair (without -n) should fix the filesystem. Quote Link to comment
Bill A Posted February 13, 2020 Author Share Posted February 13, 2020 7 hours ago, johnnie.black said: By the looks of it disk1 was likely the correct data disk, but fs is corrupted, running xfs_repair (without -n) should fix the filesystem. thqnk you for your help! disk 1 as the old data disk and running the xfs_repair without the -n was able to recover the data! Quote Link to comment
Recommended Posts
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.