October 5, 20178 yr oh weh, if it ain't one thing, ... after finally getting my ducks in a row, reading, re-reading and printing out the 3 drive parity swap procedure, I took my new 8TB drive to the physical location of the server here in Berlin (fighting rain and storms), then did the physical portion of the procedure, removing the old parity drive, putting it into the empty slot failed drive3 left after I took it out, and putting the new 8TB drive into the now empty parity slot. The server was shut down when I did this, as instructed in step #5 the Wiki Article, and I hit the power button before I left, looking at the front of the server to see all the drive lights starting to blink, and left (yes, without assuring that the server actually booted up into the WebGUI). as is sometimes the case when I am not as patient as I should be, I arrived back at my home-office just now, wanted to go to the WebGUI, but found that my server did not boot and is unresponsive to a ping...so it must have gotten stuck right after it was powered on. so now what? even if I can find a moment when the rains subside for a bit and make it back there before the agency where my server is housed closes, a forced reboot would break parity (or at least it would alert me that a parity-scan will be necessary. Is there a way for me to recover from this situation *without* having to put the old parity back in its slot and letting it do a full parity-check before attempting to do the parity swap procedure again? or in other words, if I could get my friend at the agency hit the power button for me for a few seconds and then again, would there be a way for me to do what's necessary remotely, without having to drive back there?
October 5, 20178 yr Author well, I walked back there and found that the server had stopped while configuring the controllers and spinup groups, *before* it even reached the BIOS...so after re-seating the drives I had swapped and hitting the Power button, I watched it configure the controllers and spinups groups correctly and make it to the login prompt. back at my home-office now I was able to pick up at step #5 of the instructions and just got it to start copying the parity from the old parity drive to the new one...phew! so far so good
October 7, 20178 yr Author and all kept going well until I wanted to move a number of directories to the newly striped drive3...it shows just like all the other drives of the array in unRAID's "Main" tab, and in "Stats" it shows as 0% filled, but when I start Krusader to do my file operations, drive3 is listed not as a directory, like all the other drives, but like a document with 0 B size and a modification date of 1970-01-01 (see attachment). just to double-check I ssh'd into unRAID and ran MidnightCommander, which shows disk3 with a question mark before its name and also a 0 B file size and the same date (also attached). what will I need to do to restore disk3 to normal operation? what file/log will you need from me to get the necessary insight into what could have gone wrong? puzzled again.
October 7, 20178 yr Author I wish a restart of the array had fixed it, but same issue...strange indeed. I attached the zipped diag files. unraid-diagnostics-20171007-1855.zip
October 7, 20178 yr Community Expert You need to check filesystem on disk3 (md3) https://wiki.lime-technology.com/Check_Disk_Filesystems#Drives_formatted_with_XFS
October 7, 20178 yr Author ok, will get started with that...might end up being a loong night (again).
October 7, 20178 yr Author I followed the first part of the instructions, the following output ensued...disk3 still not functioning as it should...might have to go to the "redoing a drive formatted with XFS" instructions, sadly...it's been two days of moving the old parity drive into the array while upgrading the parity to an 8TB drive...but so it does, sometimes :-/ root@unRAID:/mnt# xfs_repair -v /dev/md5 Phase 1 - find and verify superblock... - block cache size set to 155192 entries Phase 2 - using internal log - zero log... zero_log: head block 1924116 tail block 1924116 - 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 = 1 - agno = 0 - 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... XFS_REPAIR Summary Sat Oct 7 20:31:51 2017 Phase Start End Duration Phase 1: 10/07 20:30:22 10/07 20:30:22 Phase 2: 10/07 20:30:22 10/07 20:30:23 1 second Phase 3: 10/07 20:30:23 10/07 20:31:07 44 seconds Phase 4: 10/07 20:31:07 10/07 20:31:08 1 second Phase 5: 10/07 20:31:08 10/07 20:31:08 Phase 6: 10/07 20:31:08 10/07 20:31:34 26 seconds Phase 7: 10/07 20:31:34 10/07 20:31:34 Total run time: 1 minute, 12 seconds done
October 7, 20178 yr Author jeez, what a silly mistake! I'm beyond tired and probably shouldn't terminal, but I am now almost done reformatting, so let's see whether the error persists, and if it does, I'll be sure to address the correct drive...
October 7, 20178 yr Author yes, indeed it did...good thing I started off with an empty drive, phew! thanks for helping me through this, j.b., and a good night from Berlin!
October 7, 20178 yr Community Expert Your welcome, visited Berlin a few years ago, really liked it, also liked the beer a lot
October 7, 20178 yr Author yeah, amazing city and the beer to show for it...glad my city treated you well
Archived
This topic is now archived and is closed to further replies.