abuzzbuzz Posted August 27, 2018 Share Posted August 27, 2018 (edited) Hi, I was hoping someone could give me a hand with this one. Thanks Before this happened my tower had been acting funny the last couple of weeks, where twice the gui and everything stopped working. I would reboot, and it would take awhile to start the array, and show 0's when it was trying to mount the drives, so during the process, I would reboot, and it would start back up fine. Another issue I see is Disk 1 in the dashboard has a ! for SMART. I ordered another drive that was supposed to be here Sat. Oh, I just added a my first cache drive to it the other day, but I don't think that would have anything to do with it? Thanks again. tower-diagnostics-20180827-0451.zip Edited August 27, 2018 by abuzzbuzz Quote Link to comment
John_M Posted August 27, 2018 Share Posted August 27, 2018 You have two separate problems. Disk 6 has a corrupt file system so start the array in Maintenance mode and open Disk 6's page by clicking on the text "Disk 6" on the Main page. Scroll down to Check File System Status. Remove the "-n" and start the repair. Disk 1 has some SMART errors and looks as though it's beginning to fail. You can acknowledge the errors in the Dashboard by clicking on the "!". I'd run an Extended SMART test and be prepared to replace the disk. 1 Quote Link to comment
abuzzbuzz Posted August 27, 2018 Author Share Posted August 27, 2018 Thanks for the quick reply John. I really appreciate the help. What is usually the cause of a corrupt file system? Quote Link to comment
abuzzbuzz Posted August 27, 2018 Author Share Posted August 27, 2018 So, I ran the file system check without -n and got this... Quote Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... 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. I took the array offline again, and back on, still wouldn't mount. Then back into maint. mode and ran check again. Same message. Should I do the -L option? Thanks again. Quote Link to comment
John_M Posted August 27, 2018 Share Posted August 27, 2018 Normally the advice would be yes but there's something that disk expert johnnie.black recommended recently. Are you ok with the Linux command line? Basically, the plan is to try to mount the disk somewhere safe outside of the array so tat it can sort out its journal, then unmount it and run xfs_repair again. If that doesn't work then use the -L option as a last resort. Quote Link to comment
abuzzbuzz Posted August 27, 2018 Author Share Posted August 27, 2018 I am comfortable. I have done stuff in the past and worked on DOS alot as a kid. I am just not too familiar with all of the commands. Can you point me to where I might find how to do that? Thanks. Quote Link to comment
John_M Posted August 27, 2018 Share Posted August 27, 2018 Here's @johnnie.black's post: It so happens that in that case it was Disk 6 that was corrupt too, so the command will work for you as they are. Are you able to follow it? If you're unsure about anything, please ask. Quote Link to comment
John_M Posted August 27, 2018 Share Posted August 27, 2018 22 minutes ago, abuzzbuzz said: What is usually the cause of a corrupt file system? Probably a power glitch during a write. So either total loss of power (unsafe shutdown while a write is in progress) or a power cable/splitter or PSU problem. 1 Quote Link to comment
abuzzbuzz Posted August 27, 2018 Author Share Posted August 27, 2018 (edited) Well neither command was able to mount it, so I am using the xfs_repair -vL command. Have my fingers crossed, thanks. EDIT: Wow, by that other post, I thought it was going to take hours. It finished and it is now mounted! Thanks, now I have to figure out why my Docker isn't working. EDIT AGAIN: Well that fixed docker also! Edited August 27, 2018 by abuzzbuzz Quote Link to comment
John_M Posted August 27, 2018 Share Posted August 27, 2018 That's great news. Thanks for confirming it. 13 minutes ago, abuzzbuzz said: I thought it was going to take hours. It depends on how much damage there is. Thanks for trying that technique. Shame it didn't work. The loss will be minimal though. The only file affected is likely to be the one that was being written at the time of the corruption. Don't ignore Disk 1 though. Make sure you have notifications enabled. Quote Link to comment
enjoywithme Posted October 7, 2021 Share Posted October 7, 2021 On 8/27/2018 at 9:32 PM, abuzzbuzz said: Well neither command was able to mount it, so I am using the xfs_repair -vL command. Have my fingers crossed, thanks. EDIT: Wow, by that other post, I thought it was going to take hours. It finished and it is now mounted! Thanks, now I have to figure out why my Docker isn't working. EDIT AGAIN: Well that fixed docker also! Twice power off inexpertly make one disk unmountable. First time clicked format - lost whole disk data. Second time xfs_repair -vL saved me! Thanks 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.