Tiller Posted January 13, 2018 Share Posted January 13, 2018 I recently built a new server as an upgrade to my old rig. I had already transferred over all my old drives and did a parity check and everything was fine. I added a new data drive and a cache drive and everything has been working fine for a few days. Today, another new data drive finished pre-clearing and I tried to stop the array to add the new drive. For some reason, the stopping of the array got hung up, I believe on "Unmounting disks..." I couldn't get anything to change its status, so I powered down the server. Now when I power it back up and get back to the webGUI (where all drives are detected as in "Normal operation"), I click the "Start" button to start the array and perform a parity check. However, just like when I tried to stop it, it's now stuck on "Mounting disks..." I'm pretty new to all of this and the command line, so I'm not sure what to do to troubleshoot this and get everything working again. If someone could give me some guidance, it would be greatly appreciated. Quote Link to comment
JorgeB Posted January 13, 2018 Share Posted January 13, 2018 Most likely filesystem corruption on a xfs disk, after starting the array, when the GUI gets stuck, use the console or SSH into the server and type diagnostics then upload the resulting zip. Quote Link to comment
Tiller Posted January 13, 2018 Author Share Posted January 13, 2018 Here's the zip resulting from the diagnostics command. tower-diagnostics-20180113-1350.zip Quote Link to comment
JorgeB Posted January 13, 2018 Share Posted January 13, 2018 Disk5 (md5) is the one with the problem, run xfs_repair on it: http://lime-technology.com/wiki/index.php/Check_Disk_Filesystems#Drives_formatted_with_XFS Quote Link to comment
Tiller Posted January 13, 2018 Author Share Posted January 13, 2018 Okay, I'll give that a shot and see how it goes. Thanks for the help. Quote Link to comment
bonienl Posted January 13, 2018 Share Posted January 13, 2018 6 minutes ago, johnnie.black said: Disk5 (md5) is the one with the problem, run xfs_repair on it: http://lime-technology.com/wiki/index.php/Check_Disk_Filesystems#Drives_formatted_with_XFS At some point the wiki needs to be updated. A disk repair tool can be activated from the GUI when the array is in maintenance mode. The GUI takes care that the right tool - based on the file system in use - and right selected disk are chosen. Should make life easier Quote Link to comment
Tiller Posted January 13, 2018 Author Share Posted January 13, 2018 Quote root@Tower:~# xfs_repair -v /dev/md5 Phase 1 - find and verify superblock... - block cache size set to 3040896 entries Phase 2 - using internal log - zero log... zero_log: head block 196710 tail block 194435 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. This is what I get when trying it. Do I use the -L option? Quote Link to comment
Tiller Posted January 13, 2018 Author Share Posted January 13, 2018 Just now, bonienl said: At some point the wiki needs to be updated. A disk repair tool can be activated from the GUI when the array is in maintenance mode. The GUI takes care that the right tool - based on the file system in use - and right selected disk are chosen. Should make life easier How do you do it from the GUI? Quote Link to comment
bonienl Posted January 13, 2018 Share Posted January 13, 2018 1 minute ago, Tiller said: How do you do it from the GUI? 1. Start your array in maintenance mode 2. On the Main page click on the disk which you want to verify/fix 3. Turn on HELP and follow the instructions Quote Link to comment
JorgeB Posted January 13, 2018 Share Posted January 13, 2018 At some point the wiki needs to be updated. A disk repair tool can be activated from the GUI when the array is in maintenance mode. The GUI takes care that the right tool - based on the file system in use - and right selected disk are chosen. Should make life easier Yes, at some point in the past I linked the GUI instructions, but since most users didn't remove the read only flag it was more work for me, but you're right, I should start linking those instead. Quote Link to comment
Tiller Posted January 13, 2018 Author Share Posted January 13, 2018 1 minute ago, bonienl said: 1. Start your array in maintenance mode 2. On the Main page click on the disk which you want to verify/fix 3. Turn on HELP and follow the instructions Okay. I found it. Thanks. However, it is giving me the same error message I replied with before about using the -L option. So do I just go ahead and do that or are there any other things I should try since it says the -L option may cause corruption? Quote Link to comment
JorgeB Posted January 13, 2018 Share Posted January 13, 2018 Use -L, usually there's no data loss. Quote Link to comment
Tiller Posted January 13, 2018 Author Share Posted January 13, 2018 Okay, I'll run it and report back. Thanks again for all the help, everyone. Quote Link to comment
Tiller Posted January 13, 2018 Author Share Posted January 13, 2018 So it finished and I was able to start the array. Are there any steps I need to do now? A parity check? The only difference I noticed was a new share called "lost+found". Is there anything I need to do involving that? Quote Link to comment
JorgeB Posted January 13, 2018 Share Posted January 13, 2018 Parity is maintained during the repair, but since you had unclean shutdowns you should do one, other than that check the lost+plus found folder for any lost/partial files. Quote Link to comment
Tiller Posted January 13, 2018 Author Share Posted January 13, 2018 I am currently performing the parity check. All of the files in the lost+found folder seem to be 0 byte files with numbers as names. How am I supposed to interpret that? There are about 25 of them. Quote Link to comment
JorgeB Posted January 13, 2018 Share Posted January 13, 2018 If they are all 0 byte files it's most likely nothing important, probably some transactions lost because of the not replayed log. 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.