fritzdis
Members
-
Joined
-
Last visited
Solutions
-
fritzdis's post in Web UI inaccessible (flash failure?) was marked as the answerThanks!
Logs look good so far from what I can tell. Docker apps and shares appear fine. Scrubbed the BTRFS pool and scrubbing the ZFS pool now. Will do the array drives too.
Seems like it was just a hardware issue with the flash drive, and replacing it was the solution. I should have initiated a clean shutdown while I had the chance. My best guess for why I lost command line access was that the failed flash drive created those (frequent) repeated messages, which filled up the log, causing memory issues.
-
fritzdis's post in Major errors encountered, diagnostics fails, not sure how to proceed was marked as the answerVery belated update:
I'm pretty sure it was the cable connecting to the external enclosure. Reseated it and ran the server for quite a while without the new drive, but eventually, I gave the drive another go. No issues this time. Was able to run a preclear on the Toshiba to test it, build parity on it, and then rebuild one of the data drives to increase space. Running stable after the rebuild for about a week so far.
I sometimes have to move the server, so hopefully I just need to remember to carefully check that cable each time.
-
fritzdis's post in Any way to cancel BTRFS scrub on failed disk? was marked as the answerThat didn't work either (says not running). But I was able to stop the array after the other scrub finished. I unmounted all the UD devices except the failed disk (which wouldn't unmount).
The scrub errors kept appearing, so something was still going in the background, but since the only remaining mounted disk was the failed one, I went ahead and shut down the system to remove the disk. Booting back up, there's nothing concerning in the syslog, so nothing more to do on my system. And this is a rare enough situation that I doubt it needs to be addressed (since the array could be stopped, which was my main concern).
diagnostics-20230523-0910.zip
-
fritzdis's post in [Solved] Probable physical cache drive issue was marked as the answerOK, new (confusing) update:
After another reboot (because log file filled up from mover errors), here's the relevant output of lsblk -b:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdd 8:48 0 480103981056 0 disk └─sdd1 8:49 0 480103948288 0 part /mnt/cache
Somehow it fixed itself? No more of the BTRFS erros in the log yet. I certainly don't trust the filesystem on the drive to be in a good state considering all the previous errors, so I'll continue clearing off the cache in order to reinitialize it.