January 10, 20233 yr I had been using a windows install on my 2nd pc as a NAS and for a NVR for a while and kept having issues with windows and being able to access my shares on my other two pcs. So I decided to take the leap and switch to unraid for what sounded to be an easier and more reliable solution to network storage with redundancy. Unfortunately that has not been the case. I will include the sys log and diag here but I will also try to explain what has happened as best as I can, This last week and a half has been a mess of moving data, losing data, recovering all of it (I believe at least...), And frustration. About a week ago I moved all the data off my windows storage spaces to many locations in order to have empty disks to move into unraid. I had 5 4tb ironwolf pro drives in a pool. I didn't have enough space to fully empty them so removed one of them from the pool first and used that drive ( I will refer to this as drive 5) to move the rest of the data off of drives 1-4. I set that drive aside as I planned to setup unraid with the others first then use a dock on my desktop to move the data off drive 5 onto the array after it was running. My first setup was disks 1-4 without parity and I had a 1tb nvme and 1tb ssd as a cache drive. This is where it stated to get messy. After starting the array I tested it by copying (not moving) some files to it. It seamed to be great! speed was good. connecting to the share just worked as expected unlike windows, I was relived. After the first copy I waited to it to empty the cache drive and decided i would rater use the ssd as its own share instead of for cache as it would only slow down the nvme drive (at least i assume) So I removed it from the cache and added it to the array. I then setup my only share to exclude this ssd ( i think it was disk 6) as I planned to make a share only for the ssd. But as i started moving (not copying unfortunately) data off of disk 5 to the array i noticed that the ssd (disk 6) was filling up and data was not moving to the hdd share. So in fact the opposite of what i expected to happen was happening. The ssd (6) quickly started to overheat and the writes where constantly climbing without any transfers happening. I knew something was wrong when i seen the ssd(6) in the array was btfs and not xfs. I was able to access the share and start pulling all the files back off at a blazing 1-3 mbps. It took days. But I got everything i needed back. At this point disk 1-4 where still empty. and now the ssd and cache where empty as well. But with the ssd overheating so badly for so long I decided it best to not use it in the array at all and just stick with my hdds and nvme. even though all the drives had no data on them aside from unraids own app data folders etc it wouldn't let me remove the ssd form the array and still start it. But as I had noting on it I just assume use the new config option and start over. After the first scare I decided this time to use disk 1 as a parity drive and disk 2-4 as the array disks. and just the nvme as a cache. All went smoothly. After 2 days of no Issues and the peace of mind of a parity drive I decided to again attempt to move the data off of disk 5 onto the share so I could empty the disk and add it to the array. This time out of fear of something going wrong i decided to copy the files first and verify it worked. As expected all the data moved to disk 2 (listed as disk 1 in the array) and I was able to see and use the files to be expected. So deleted the contents of drive 5 and added it to the array. I expected the preclear disk plugin to see the drive and give me option to clear the disk but it didn't so I assumed it was because it was still NTFS but unraid gave me the option to format the unmountable drive and it was already empty so I figured what the heck as it was the only drive listed in the unmountable drive section. After doing so I still figured I should do a preclear on it after reading a bit on here and decided to reboot to see if the preclear plugin would see the disk. And it did. while that disk was being cleared I moved a new set of data to the array ( ill call this data 2) Data 2 moved over no issue and the preclear finished so I added the disk to the array. It then said it was running its parity processes and I figured it was since it had a new disk that it needed to account for. It completed without errors and i then shutdown the system to add 2 more fans to the case. When I turned it back on disk 5 (listed as disk 4) said unmountable or incorrect filesystem or something along that line and that line and that the contents was emulated and that it needed to rebuild parity. I assumed this would not be an issue as the drive was empty anyway. So I let it run in fear that stopping it would cause issues with my parity or other data. After it was done I turned the system off as I was now worried something was not right as i could no longer see my old data in the share (data 1) but Data 2 was there. Now Disk 2 (listed as disk 1) is showing Unmountable. And data 1 is not on the share. I hope this is fixable and Ive now seen the mention to not shutdown the sys as it clears the log but I hope its not too late. I consider myself to be great with pcs and networking but this has really given me more issues than I expected and im out of my comfort zone when it comes to things outside of windows or homeassistant. If anyone has time to voice chat on discord to teams etc I would be very grateful for any insight on how to do this right and make it reliable and redundant. I cant handle the stress of losing data anymore. ( i plan to backup offsite once this is all setup and my data is not sitting on 8 different pcs and external hdds) If Voice chat is not preferred I will also appreciate any advice in the form of replies on this thread. Thanks in advance for any help you can provide! tower-diagnostics-20230110-1413.zip tower-syslog-20230110-2013.zip
January 11, 20233 yr Community Expert Sorry nobody has responded yet. I had to go out for a while when you first posted. Not sure I am totally clear on the whole story of how you got to this point, but diagnostics should make it clearer exactly where you are now. And that is probably the most important thing since it is what we have to work with. For future reference, please don't refer to any disk as disk1, etc. except for a disk already assigned as disk1 in the parity array. You were juggling those numbers in the same sentence up there. Come up with some other naming scheme. The last 4 characters of the serial number is a good scheme to use since it will allow us to keep track of the disks wherever they are, and will also agree with the way Unraid keeps track of disk assignments (by serial number). Let me study diagnostics for a moment.
January 11, 20233 yr Community Expert Diagnostics already includes the current syslog, so no need to attach it separately. Current syslog is in RAM like the rest of the OS so it can't show us anything that happened before boot. Disk1 was already unmountable when it booted, no way to know what might have caused it. No obvious I/O errors in syslog (yet). Other than that your configuration looks good.
January 11, 20233 yr Community Expert @KevinJ Check filesystem on disk1 from the webUI. Be sure to capture the output and post it.
January 11, 20233 yr Author Ok thanks very much for your input and I will do that now and post the results
January 11, 20233 yr Author @trurl I hope this is what you where looking for. Phase 1 - find and verify superblock... - block cache size set to 1505784 entries Phase 2 - using internal log - zero log... zero_log: head block 128193 tail block 128188 ALERT: The filesystem has valuable metadata changes in a log which is being ignored because the -n option was used. Expect spurious inconsistencies which may be resolved by first mounting the filesystem to replay the log. - scan filesystem freespace and inode maps... sb_icount 19968, counted 46016 sb_ifree 16, counted 13 sb_fdblocks 709982218, counted 180279957 - 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 = 3 - agno = 2 - agno = 1 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... No modify flag set, skipping filesystem flush and exiting. XFS_REPAIR Summary Tue Jan 10 18:00:50 2023 Phase Start End Duration Phase 1: 01/10 18:00:43 01/10 18:00:43 Phase 2: 01/10 18:00:43 01/10 18:00:43 Phase 3: 01/10 18:00:43 01/10 18:00:47 4 seconds Phase 4: 01/10 18:00:47 01/10 18:00:47 Phase 5: Skipped Phase 6: 01/10 18:00:47 01/10 18:00:50 3 seconds Phase 7: 01/10 18:00:50 01/10 18:00:50 Total run time: 7 seconds
January 11, 20233 yr Community Expert That doesn't look too bad. Do it again without -n. If it asks for it use -L
January 11, 20233 yr Author Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... 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... clearing needsrepair flag and regenerating metadata sb_icount 19968, counted 46016 sb_ifree 16, counted 13 sb_fdblocks 709982218, counted 180279957 - 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 = 3 - 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... Maximum metadata LSN (1:128145) is ahead of log (1:2). Format log to cycle 4. done
January 11, 20233 yr Community Expert Start the array in normal (not Maintenance) mode and post new diagnostics.
January 11, 20233 yr Author @trurl you are a wizard! Its all back and working as expected! You just made my day. I will still include the diagnostics in case. tower-diagnostics-20230110-2041.zip
January 11, 20233 yr Community Expert Solution Looks good. Nothing even got lost+found. This was an easy one
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.