March 1, 20179 yr Hello all and apologies in advance for my ignorance. Long story short, flash drive went bonkers and after 5am I made a poor decision. I had been up for hours trying to salvage my server and threw corrupt files onto a new usb and plugged it in. In my sleeplessness I forgot to remove disk.cfg and/or super.dat and my array booted up. I thought I had gotten to stop the parity check in time but that may not have been the case. I'm honestly not sure of what happened because I was in such a daze from a long day and restless night. Today I'm of clear mind so I started a new install but it seems that when I assign either of my 2 (one was data, one was parity) to data they both come up unmountable. They're identical drives so aside from remembering which serial number is which I can't be sure of what drive to put where. Is there something I can do to check which drive is the data and which is the parity? If I plug it into my pc running mint will it recognize and read the drive? Or if it's unmountable on UNRAID it's unmountable everywhere. Any advice or guidance would be greatly appreciated.
March 1, 20179 yr Community Expert Extremely unclear what you have done. Nothing in your description would make me think a parity check would cause any problem. And in the case of only 1 data and 1 parity the disks are just mirrors of each other anyway. See if you can remember exactly what you did and give us a clearer description.
March 1, 20179 yr Author Things get blurry when I'm tired, so I apologize for the lack of details. As far as I remember I think I was upset that the drives may have switched places? IE: The data drive got selected to be the parity and vice versa. I remember seeing the message of "ALL DATA ON THIS DISK WILL BE ERASED WHEN ARRAY IS STARTED" for the parity. I'm wondering if at some point in the night I tried to start the array with one of the drives in the wrong position, thus erasing data on both drives? But if they're just mirrored that shouldn't be a problem. Being completely honest I make some quite dumb and rash decisions whilst tired. I think at one point I started a fresh install but copied over my config folder from a backup in november. I know the lack of details is incredibly frustrating, I appreciate your patience.
March 1, 20179 yr IF you had simply started the array with the two disks interchanged, a parity check should have still resulted in the same mirror you started with (since you only have two disks in the array). HOWEVER ... if that was the case, you should still be able to see the data on either disk => i.e. they shouldn't show as unmountable. So clearly you did something else that has messed up the structure of the drives. You can TRY mounting one of them on another Linux system and see if it "sees" the drive okay -- but I suspect it will not. You can also try running fsck (or reiserfsck if the disk happens to be reiser -- I suspect that's not the case). But realistically I think you've wiped out your data.
March 1, 20179 yr Community Expert If you are using xfs array won't start with both as data disks, since they'll have the same UUID, if you just assign one of them, either one in this case, the disk should mount.
March 1, 20179 yr Author I'll try my best to piece together my memory. As of right now I once again located my old backup from November and threw that onto a usb. It came on with my old settings and is saying a disk an unmountable, but is attempting a parity check. I'll report back later when I get back from work on how badly I've messed up. Thanks for the thoughts so far. Edit: Thank you for the info, johnnie. Out of curiosity - what happens if the parity finishes and finds everything is okay? Am I then able to format the data drive and hope the parity puts all the info back? Sorry for the ignorant question, I have no idea what I'm doing. Edited March 1, 20179 yr by unraidMN
March 1, 20179 yr Community Expert 17 minutes ago, unraidMN said: Out of curiosity - what happens if the parity finishes and finds everything is okay? Am I then able to format the data drive and hope the parity puts all the info back? Sorry for the ignorant question, I have no idea what I'm doing. Absolutely not. Format is a write operation. It writes an empty filesystem to the disk. unRAID treats that write operation just like any other write, by updating parity. So after a format, parity will agree the disk has an empty filesystem. Do you know what filesystem the disk should be? Perhaps it is expecting XFS (default in V6) but you actually have ReiserFS disks and that is why it thinks it is unmountable.
March 1, 20179 yr Author I installed UNRAID a year ago, setup my plugins, then left it be. I can't imagine I'd swap a filesystem to something other than default. Is there a way to check? Throwing in a liveUSB with gparted or something of the sort?
March 1, 20179 yr Community Expert Default should be xfs, I'm pretty sure your problem is the duplicate UUID but posting the diagnostics after trying to start the array would let us confirm.
March 1, 20179 yr 2 hours ago, trurl said: Do you know what filesystem the disk should be? Perhaps it is expecting XFS (default in V6) but you actually have ReiserFS disks and that is why it thinks it is unmountable That wouldn't cause any issue -- v6 can mount Reiser disks just fine. The default file system has NO impact on current disks -- it's just what is used for new disks.
March 1, 20179 yr 1 hour ago, johnnie.black said: I'm pretty sure your problem is the duplicate UUID That seems very likely => if both disks were assigned as data disks, that would explain it.
March 1, 20179 yr 2 hours ago, unraidMN said: As of right now I once again located my old backup from November and threw that onto a usb. It came on with my old settings and is saying a disk an unmountable, but is attempting a parity check. This was not really what you wanted to do. But when it finishes, post the results. 2 hours ago, unraidMN said: Am I then able to format the data drive and hope the parity puts all the info back? NO -- whatever you do, do NOT format the disk. This will completely empty the file system.
March 2, 20179 yr Author Quote Parity is valid Last checked on Wed 01 Mar 2017 06:05:53 PM PST (yesterday), finding 1198 errors.Duration: 7 hours, 4 minutes, 12 seconds. Average speed: 117.9 MB/sec Above are the results of the parity check. Should I upload the full zip of diagnostics? Edited March 2, 20179 yr by unraidMN
March 2, 20179 yr Community Expert You need to check filesystem on disk1.https://lime-technology.com/wiki/index.php/Check_Disk_Filesystems#Redoing_a_drive_formatted_with_XFS
March 2, 20179 yr Author " If you don't know for sure, then go to the Main page of the webGui, and click on the name of the drive (Disk 3, Cache, etc). Look for File system type" When I goto Main and look under FS it shows nothing.
March 2, 20179 yr Community Expert You need to check filesystem on disk1.https://lime-technology.com/wiki/index.php/Check_Disk_Filesystems#Redoing_a_drive_formatted_with_XFS
March 3, 20179 yr Author When I click on the drive I get taken to a different page, but "options for that drive, beginning with various partition, file system format, and spin down settings." are not amongst them. Attached is what I see.
March 3, 20179 yr Community Expert 18 minutes ago, unraidMN said: When I click on the drive I get taken to a different page, but "options for that drive, beginning with various partition, file system format, and spin down settings." are not amongst them. Attached is what I see. According to your diagnostic from yesterday, sdc is your disk1, and the url in your screenshot says name=sdc, but it should say name=disk1. That looks like a screenshot and URL from an Unassigned Device. Have you unassigned your disk1?
March 5, 20179 yr Author *Face Palm* What an oversight. It's now assigned and I now see the option to do xfs_repair. Below is output. Quote Phase 1 - find and verify superblock... - block cache size set to 2214008 entries Phase 2 - using internal log - zero log... zero_log: head block 2142006 tail block 2142006 - scan filesystem freespace and inode maps... - 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 - 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 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... Maximum metadata LSN (24:2142231) is ahead of log (24:2142006). Would format log to cycle 27. No modify flag set, skipping filesystem flush and exiting. XFS_REPAIR Summary Sun Mar 5 11:03:01 2017 Phase Start End Duration Phase 1: 03/05 11:02:18 03/05 11:02:18 Phase 2: 03/05 11:02:18 03/05 11:02:19 1 second Phase 3: 03/05 11:02:19 03/05 11:02:41 22 seconds Phase 4: 03/05 11:02:41 03/05 11:02:41 Phase 5: Skipped Phase 6: 03/05 11:02:41 03/05 11:03:01 20 seconds Phase 7: 03/05 11:03:01 03/05 11:03:01 Total run time: 43 seconds Edited March 5, 20179 yr by unraidMN formatting
March 6, 20179 yr Author [quote]Phase 1 - find and verify superblock... - block cache size set to 2214008 entries Phase 2 - using internal log - zero log... zero_log: head block 2142006 tail block 2142006 - scan filesystem freespace and inode maps... - 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 - 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 Phase 5 - rebuild AG headers and trees... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - 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 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... Maximum metadata LSN (24:2142663) is ahead of log (24:2142006). Format log to cycle 27. XFS_REPAIR Summary Mon Mar 6 12:24:36 2017 Phase Start End Duration Phase 1: 03/06 12:22:15 03/06 12:22:15 Phase 2: 03/06 12:22:15 03/06 12:22:16 1 second Phase 3: 03/06 12:22:16 03/06 12:22:39 23 seconds Phase 4: 03/06 12:22:39 03/06 12:22:39 Phase 5: 03/06 12:22:39 03/06 12:22:39 Phase 6: 03/06 12:22:39 03/06 12:22:57 18 seconds Phase 7: 03/06 12:22:57 03/06 12:22:57 Total run time: 42 seconds done OMG, it's back! Thank you all for your help and patience. Edited March 6, 20179 yr by unraidMN
March 7, 20179 yr Author Parity check successful. Is there a way to easily get my shares back? It looks like they're all in my config/shares folder but aren't in the shares tab Fixed: For some reason global sharing was on auto, just switched to enabled. Onto the next problem! Edited March 7, 20179 yr by unraidMN Fixed.
Archived
This topic is now archived and is closed to further replies.