jkBuckethead

Members
  • Posts

    31
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

jkBuckethead's Achievements

Newbie

Newbie (1/14)

10

Reputation

  1. I recently upgraded a drive in my SSD cache pool. I probably would have been fine without, but before replacing the drive I moved shares that normally reside on the cache to the array. Most importantly I wanted to move my large Plex appdata folder. To move the shares, I changed their cache preference from PREFER to YES and ran the Mover. I also stopped all dockers and disabled auto-start so that the files would not be in use. After the cache upgrade, which had no issues, I changed the shares back to PREFER and started the Mover again. Once finished, I checked the array disks for any lingering folders or files, and I found some. There aren't many, just one .icons folder from Krusader that seems to be empty, and six Plex metadata .bundle folders. The Plex folders are spread across five folders in one library, so just one or two subfolders in folders that normally contain hundreds of these .bundle folders. When I explore the bundle folders deeper, there are several more levels of subfolders but ultimately they all appear empty. This means I don't think there is really any data to be worried about, just folders that need to be cleaned up. I didn't previously have mover logging enabled, but now I do. The most recent mover operation is very close to the end of the attached log. What seems interesting is that the the mover is trying to move files (that do not exist), that have the same paths as the few folders still remaining on the array. I guess instead of deleting the empty folder path, Mover left the empty folders behind. Is there a way to force Mover to clean up the folders? Can I safely remove them manually? Should I ignore them since they take up no space? unbucket-syslog-20210624-0045.zip
  2. I have not shucked an 18TB drive, but I have shucked several 10 and 12TB Elements and MyBook drives. In all cases, they were SATA drives. Once installed they identify as Wester Digital Ultrastar He10/12 drives. I did have to tape off the 3rd pin to make them work with SATA power connectors but that was pretty easy.
  3. For a few weeks now, my server has been locking up every weekend. At first I didn't notice the regularity, but this week I noticed the uptime was 6 days and 20 hours when I was dealing with it. Considering I woke up around 3:30 AM and started messing with it, the uptime would have been right at 7 days if I had waited until morning to take care of it, like usual. The lockup first becomes apparent because the network shares become unavailable to file explorer and any other applications using the shares. While the shares are unavailable, the webGUI is still partially working. The exact state of the webGUI has been different each week. Some pages load fully, while others only load partly. For example, the past few weeks the MAIN page would load, except the Array Operation section at the bottom would be blank. In each case I have been able to access the page to download diagnostics, but until this week the diagnostics never would actually download. The week the diagnostics did finally download so I have something to upload. Recovering from the lockup always ends in me shutting down manually and restarting, which of course is followed by a parity check. I have tried shutting down via the webgui and the terminal window without success. With a monitor connected to the server, when I try powering down from the terminal window I can see the process starting, but it never finishes and actually shuts off the hardware. Since this week the webgui was a little more complete (i.e. Array Operation was loading) I got to see a little more info than past episodes. One interesting thing is it indicated Mover was running, but no actual disk activity was indicated. I don't know if that is significant, it's just something I saw. The regularity of this happening every saturday night/sunday morning made me look for a corresponding scheduled event. I have a number of things that check overnight, such as application updates that check daily, the only weekly item I found was SSD Trim (enabled for my cache SSDs) set for Sunday at 2AM. I am going to disable Trim for now and see if it solves the problem. Any thoughts on Trim locking up the system? UNBUCKET Main 09052020c.pdf unbucket-diagnostics-20200906-0331.zip
  4. Thanks, you've confirmed my thoughts. I knew I could turn on the PSU with a jumper, I just didn't know if there was a reason I shouldn't.
  5. Seems like your response is closest to what I want to achieve. If nothing is connected to the MB, then you are controlling the PSU directly. Not clear whether your remote switch is connected to the incoming power or the PSU output. Please clarify how you are turning the PSU on and keeping it on. Did you install a permanent jumper on the 24-pin connector and now you are switching the power from the wall? Or, is your electronic switch connected to the 24-pin connector? Either way would confirm my thought that using a jumper to activate the PSU, whether the jumper is solid or switched, is all I need to turn the PSU on.
  6. Thanks for the input, both of you. Not keen on the idea of splicing into my PSU cables. I'd need a pair of 24-pin extensions so I could splice into them without permanent damage to my PSU cables. Plus, I would need some sort of connectors at the back of the machine for easy disconnection when I need to move them. Cheaper than the supermicro widget, but still probably $15-20 in parts. Both of these solutions would require additional cabling between the two enclosures. I'm not aware of any off the shelf cables that would work for either option so I would have to rig something up using adapters and old cable parts. I might even have to solder, which I suck at. I'm not concerned about keeping the PSUs in sync. Except for upgrades and/or repairs, this server runs 24/7. I think I'll try to stick with a solution that doesn't involve extra connections between the two machines.
  7. Looking for a little room to grow. Planning on using one of the currently available mini-ITX enclosures with 8 hot swap bays to house the drives and connecting to an external SAS HBA in the main system with a pass-thru in the back of the case. I know that on a dollar per bay basis I would be better with a used server chassis, but I don't need that much expansion and I don't have anyplace to mount a server chassis. My question is how to power the external chassis since I won't have a motherboard. Do I really need something like the SuperMicro JBPWR2 Power Board or can I simply turn on the PSU with a jumper? If all I need is a jumper for the PSU, looking at this switch to make powering off and on easier. If I need something more, I also have an old ASUS AT5IONT-I board with an integral Atom CPU lying around collecting dust. I'm thinking I could also use it to control the PSU, and it would just be in a constant state of failed boot without a boot drive. This would waste a bit of power, but with a 13W CPU not too much.
  8. I have had no issues using the Aquantia AQtion 10G Pro NIC in my unraid machine. The card is multi-gig so it supports 1, 2.5, 5, and 10G depending on the connection at the other end and the length and quality of the cable. In my case it sits right next to my main switch with a CAT 7 patch cord connection, but is limited to 5G because it is connected to a 5G port on my switch. Still, with spinning hard drives this is more than enough speed.
  9. A couple of weeks ago, completely out of the blue I saw I had errors on two storage drives plus one of my two parity drives was offline. The first sign something was weird was that both storage drives had the exact same number of errors. This would be a huge coincidence if it was physical drive failures. It turned out that all three drives were connected to the same breakout cable (the 4th was unused) on my LSI 9207-8i HBA. Thinking it might be a bad cable, I swapped out the cable and rebooted. I rebuilt the 2nd parity drive and everything has been fine for the past two weeks. Tonight, I updated to version 6.8.1. Right after rebooting I saw a strange warning message that one of my cache drives was unavailable. Oddly, when I checked the drive on the MAIN page it said the drive was operating normally. A few minutes later, the same parity and two storage drives started having similar problems as before. While on a different breakout cable, the cache drive is connected to the same HBA as the other malfunctioning drives. I shut down and swapped the HBA for a spare I just bought for another machine. It seems like the HBA may be sketchy. I prefer not to put the HBA back into service without confirming it is healthy. I also don't want to buy another if not necessary. Does anyone know of any software tools or other methods for testing an HBA? unbucket-diagnostics-20200113-2308.zip
  10. Best Buy is currently offering $90 off on the 10TB Easystore, making it $159.99. This is $30 less than the 8TB at $199.99. They also have $100 off on the 14TB model, making it $209.99. If you can go big, $15/TB is not too shabby. No deal on the 12TB so it is $249.99.
  11. Thanks to all. The file system status check with the -L switch seems to have done the trick.
  12. Unfortunately I tried both, but with no positive results. First I tried xfs_repair from the terminal window, which seemed to return an error and stop. I can't figure how to copy text from the terminal window so I've done my best to repeat the results below. xfs_repair result Phase 1 - find and verify superblock... - block cashe size set to 323016 entries Phase 2 - using internal log - zero log... zero_log: head block 116006 tail block 116002 ERROR: The filesystem has valuable metadata changes in the 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 file system before doing this. I checked out the -L option under xfs_repair, and it had this to say: -L Force Log Zeroing. Forces xfs_repair to zero the log even if it is dirty (contains metadata changes). When using this option the filesystem will likely appear to be corrupt, and can cause the loss of user files and/or data. Since this didn't sound promising, I moved on to the webGUI option. The webGUI option first returned an ALERT that was similar to the error above, but still essentially cautioned to first mount my (unmountable) file system. It did however complete the scen, the results of which are below. The wiki indicates that the file system check should clearly indicate what steps should be taken if a repair is required. Maybe I'm missing something, but I do not see any suggestions below. Since nothing was suggested, I restarted the array normally and still the disk is unmountable. With no obvious error, does this mean my disk is toast? My replacement should arrive tomorrow. Is rebuilding from parity the bet option? After that I can pull the disc and more thoroughly test it. webGUI file system check results Phase 1 - find and verify superblock... - block cache size set to 323016 entries Phase 2 - using internal log - zero log... zero_log: head block 116006 tail block 116002 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... - 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 - agno = 4 - agno = 5 - 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 = 2 - agno = 3 - agno = 4 - agno = 5 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... Maximum metadata LSN (1:120049) is ahead of log (1:116006). Would format log to cycle 4. No modify flag set, skipping filesystem flush and exiting. XFS_REPAIR Summary Thu May 16 18:40:32 2019 Phase Start End Duration Phase 1: 05/16 18:40:31 05/16 18:40:31 Phase 2: 05/16 18:40:31 05/16 18:40:31 Phase 3: 05/16 18:40:31 05/16 18:40:32 1 second Phase 4: 05/16 18:40:32 05/16 18:40:32 Phase 5: Skipped Phase 6: 05/16 18:40:32 05/16 18:40:32 Phase 7: 05/16 18:40:32 05/16 18:40:32 Total run time: 1 second
  13. DITTO, the same thing happened to me. The common problems plugin notified me of an issue. The error was "Unable to communicate with GitHub.com" but I have also determined that my Plex server (running as a docker) is not available outside of my network. Fortunately I have no problem seeing the server or my unraid shares on my local network. I checked the network settings and discovered that the motherboard ethernet port, which has been disabled for many months in favor of a mellanox 10Gb network card. I set interface back to PORT DOWN and rebooted. Unfortunately after rebooting the server still cannot connect outside of my network. EDIT I rolled back the OS to version 6.6.7 and the network connectivity issues are gone. No settings changes, just the OS version. Definitely looks like a network issue with OS 6.7.0. unbucket-diagnostics-20190516-0320.zip
  14. Got home from work today, and happened to see that a new unraid version was available so I decided to upgrade. I backed up the flash drive, and then I ran the upgrade assistant tool, which advised me to upgrade a couple of plugins, which I did. Plugins sorted I started the upgrade, which completed just fine and told me to reboot. Upon rebooting Disk 4 is now showing as "Unmountable: No file system". Prior to the upgrade I didn't notice any issues or warnings. About 3 weeks ago the server did shut down abnormally when a power outage exceeded my UPS standby time, but it had been running fine since being restarted. I have only tried the most basic troubleshooting. I tried restarting with no change. I also tried a new SATA cable and swapping SATA ports on the motherboard, but the error remains on the original disk 4, not the cable or port. I have attached my diagnostics tool zip file. I don't have a spare disk at the moment because I used it on another system, but I already have on order. In the meantime I have shut down the server since it houses less than critical data that I can live without for a few days. While I wait, I would like to know what happened, in case it's something that I did or something otherwise preventable in the future. While I wait for the replacement drive I guess I need to read up on how to replace a drive and rebuild the array since this is my first failure since starting to use unraid. EDIT Rolled back the OS to version 6.6.7 but the drive is still unmountable. Seems like maybe it is a drive issue that just didn't show up until the system was reboot. ghost-diagnostics-20190516-0154.zip