TDD

Members
  • Posts

    66
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed
  • Personal Text
    Keeping the hard drive manufacturers in business.

Recent Profile Visitors

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

TDD's Achievements

Rookie

Rookie (2/14)

7

Reputation

  1. I have never had an error post-fix. It is entirely possible that Seagate is making changes to the firmware hence these variances we are seeing...? Kev.
  2. I apologize if this has been cited, but more often than not it is necessary to completely power down and ensure the drives have zero power then start up. Just like updating your motherboard BIOS. Other than that, AFAIK the issue is only with the mentioned models. The fix has held for me since day one of application. Kev.
  3. Roger that. I'm considering moving my dockers to their own IPs across the board rather than all bridged to the UnRaid IP and ports. It should be as simple as moving each to br0 then manually specifying an IP that is not taken anywhere else in my lan. This works for Plex which I have moved. For those dockers that like inter-docker chatter like Sonarr, I cannot get it to see any of its targets like qBittorrent, Jackett, etc., even if they are on the same br0 and their own IPs (and Sonarr correctly set to point to the new dedicated IPs). I have docker set to allow 'host access to custom networks' just in case. Of note is these targets are dockers with internal VPNs which is blocking things I suspect. What is magical about the bridge mode by default in docker (which works) against a custom ip and the br0? Do I need to make another custom bridge (br1) in my subnet and have all the dockers ride that? Docker settings show the subnet as 192.168.0.0/16 and my correct gateway for my lan (192.168.1.1 on my 192.168.1.x). Ensure the routing table reflects br1 on the 192.168.1.x? This seems like an adventure. Kev.
  4. Has this been fixed? I have the same issue as I move dockers to their own IPs. Legacy forwards still show. I've moved Sonarr to port 80 internally but cannot purge this display. Note that a 'docker ps' shows it clear as it should. Kev.
  5. It may - or it may not. Depends on firmware specific to each model. The good thing is the SeaChest modifications are applicable and should be able to handle any quirks. Kev.
  6. The full tweak allows spin downs gracefully so you give up nothing. Might even save a watt or two :-). Kev.
  7. I want to add that my solo 8TB drive, my parity, does spin down and up as needed and does not always spin. This fix does not affect any requests to go idle. Kev.
  8. My 8TB Ironwolf was the sole Seagate and it was the parity that errored out. It all comes down to strictly how idle the drive is and spin-ups past that. Kev.
  9. There very well could be edge cases with other Ironwolf drives but assuredly it is an issue with the ST8000VN004. I would not bet on a timely, if ever, firmware update for the drive itself. The two changes make the drive more aggressive with its spinup and readyness to compensate for the driver timing out while waiting for its ready state. You have nothing to lose by making these changes as they are reversible; the amount of power saving is negligible IMHO and the benefits of a upgraded UnRAID are worth it. Try and see! Kev.
  10. I only know of the exact 8TB unit in question that requires this tweak. I presented Seagate all the info on the issue but got meaningless responses back. Was hoping to chat with the hardware/firmware guys. We can only hope the intel makes it to where it needs to be. For note, my testing was done on both my LSI controllers and the same outcome was found prior to the fix: [1000:0064]01:00.0 Serial Attached SCSI controller: Broadcom / LSI SAS2116 PCI-Express Fusion-MPT SAS-2 [Meteor] (rev 02) [1000:0072]02:00.0 Serial Attached SCSI controller: Broadcom / LSI SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] (rev 03) Kev.
  11. Linux guy here. Use the Ubuntu ones. If they don't work for unknown reasons, I have an archive of the older tool set. Kev.
  12. Thank you for the work bringing this together. There is an easy way to just target the disks you want to modify. SeaChest_PowerControl_1100_11923_64 -s --onlySeagate I believe most tools actually allow this -s switch. See screenshot. This allows you to skip the 'map' part and make this easier :-)! Kev.
  13. Try the EPC disable/low current disable per my posts. They are reversible if nothing better happens after reboot. I've had no issue since. Kev.
  14. You won't notice much of a difference, if any, toasting EPC and spin. Try just the EPC if you are inclined. Drives will still spin down. It's not like your power bill will double. All we are doing here is making the drives way less aggressive with their sleep modes so the controller doesn't freak out. I'd rather this fix than the alternative of drives dropping. I believe it to be an issue in any recent merge into the combined mpt3sas driver and kernel. It was all fine under 4.19. Disable and await any non-firmware fixes later. You can then re-enable the aggressive power saving if you wish. I have had zero issue since this fix across all my controllers that are LSI based. Kev.
  15. See my earlier post on how I fixed this. I have had no issues since. Kev.