My Seagate warranty saga

“No joy” meaning you couldn’t talk to those drives (e.g., because of the USB bridge), or rather you used that command and it didn’t work? It works for me without any problems.

Correct most drives (at least from Seagate) do not pass SMART so you cannot use this method.

I wanted to create one universal way to keep ALL drives spinning so that’s why I opted out for read script.

Then most likely the problem is that -d flag. By default, smartctl doesn’t scan drives for what protocol they use. Therefore, you need to run that ‘smartctl --scan’ and smartctl will try everything it can to talk to every drive and will give you back the flag that you need to use.

OK let me clarify on Seagate’s smartctl can technically “talk” to the drive but it does not appear to be able to do anything and drive always stays in sleep mode. I even tried using hdparam to try to change advanced power management on the FW side but Seagate’s do not allow any tweaking from my experience. Plus, smartctl -a on Seagate fails. On and --scan reports “sat” for Seagate’s same as WD but still no luck working with the controller on these drives probably due to the USB bridge they use.

Seagete PUB:
sudo smartctl -n never /dev/sdu
smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.4.0-94-generic] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke,

Device is in SLEEP mode

vs WD EasyStore/Elements:
sudo smartctl -n never /dev/sdq
smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.4.0-94-generic] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke,

Device is in IDLE_A mode

Reading SMART on Seagate drives:
sudo smartctl -a -d sat /dev/sdu
smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.4.0-94-generic] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke,

Read Device Identity failed: scsi error unsupported field in scsi command

A mandatory SMART command failed: exiting. To continue, add one or more ‘-T permissive’ options.

I write to the drives so that if the drive becomes unavailable, I will know (within an approximate 90 second range) when the drive went on vacation.

I have been using the script for months, and my drives stopped sleeping.
The drives that refuse to stay awake (when idle) are the WD G-Technology line of drives.

I have 10, and have no plans to add more.

I have several of each of those drives.
The Seagate Backup +Hub drive has similar performance. Also, drives connected to its hub show no sign of performance degradation.

For a daily driver, general use PC, I would do that.
But for my Chia related computers, I will install no 3rd party software, unless the need is urgent.

Windows has a way of becoming degraded over time (not as bad as years ago, but still it magically gets cluttered). I am keeping my Chia systems clear of anything that was not included in the OS installation (which I know is bloated – but I will not add to that with software from other vendors).

In fact, I will not use my Chia system’s web browser. The only internet activity taking place is Windows Update and Chia blockchain activity. Web browsers have a way of installing crap via java scripts, etc.

My USB drives are not set up for that “Safely Remove Hardware” option. Unless Chia is writing a new plot (which is no longer the case, as the wallet has run dry), there are no write requests to my plotted drives (other than my keepalive.bat script – which, if I lose power for long enough for my UPS battery to die, will not matter if that script fails).

All of you points are valid. But it depends on the circumstances. Mine are such that things are working.

I used to work for Atlantic Records. In a common area, they had a sign that read:
“If it ain’t broke, fix it!”

It was funny, and meant to dissuade employees from tinkering with what works, albeit sarcastically.

I am, however, always in favor of improving things, depending on the time and risk level.

If it reports SLEEP mode, it most likely woke up your drive. Try issuing that command again, and it should return with a non SLEEP mode.

If for instance you would use -n IDLE, and the drive would be in SLEEP mode, the command would come back with nothing, i.e., it would ignore that drive letting it be in the SLEEP mode.

That is the logic board power down, but not platters (my understanding of it). If it returns with IDLE_B, that is related to platters. Those are newer modes. So, there is no need to worry if IDLE_A is returned.

Since you could talk to /dev/sdu without -d flag, it looks like it is not needed in this case.

Seagate drives ALWAYS return SLEEP mode even when repetitively issuing smartctl command and the fact that SMART cannot be read on them leads me to believe that they cannot be controlled hence the need for a workaround script.

I believe the IDLE_A mode is the controller low power mode but like you said in this mode the drive does not power down the spindles. Issuing smartctl -n never again few times still does not bring the drive to ACTIVE mode.

The only time smartctl returns drive in ACTIVE mode is right after my script runs so this is why I think that smartctl cannot keep the drives spinning at least in all cases.

The -d sat parameter does not have to be issued, I just issued it to show you that even when using it, which was suggested by --scan, does not help in reading SMART on Seagate USB drives. I think SAT does not have to be issued because I have smartctl service running continuously monitoring the drives and I think that remembers the -d for each drive.

1 Like