[smartmontools-support] I can't complete the long test

[Carlos E. R.]

On 07/05/2021 16.13, Nathan Stratton Treadway wrote:
> On Fri, May 07, 2021 at 12:59:48 +0200, Carlos E. R. wrote:
>> As Nathan said, it is the usb chipset which is the culprit, it is seen 
as
>> the "host". I didn't realize this. The daemon doesn't influence things.
> 
> Well, to be precise, the smartd daemon's activity does help keep the
> drive "awake" (and would do so even more if you removed the "n standby"
> from the drive's line in smartd.conf).

I thought so to, but that "n standby" solved another problem in the past 
and I had to add it. Let me search... here:

<https://listi.jpberlin.de/pipermail/smartmontools-support/2020-October/000528.html>

basically, smartd complained in the log each time it wanted to read 
something and the device was asleep, then sent an email, which was a 
baaaad nuisance.


> But because smartd only runs once every 30 minutes, even without -n
> standby it's probably not frequent enough to keep the drive awake for
> the duration of a full self-test (depending on the firmware timeout
> setting).
> 
> 
> 
>> So, perhaps I have to run a cronjob simultaenously with smartd testing 
to
>> force the disks to stay awake to be tested, or forget automated (long)
>> testing and do it manually when I want, as anyway the testing takes almost a
>> day.
> 
> 
> Personally I don't attempt to use smartd to run long self-tests for
> USB-connected drives and just do them manually from time to time (since
> I don't leave them plugged in most of the time and so running a long
> self-test also involves planing to leave it plugged in).

One disk is plugged full time, and the other is plugged eventually. The 
idea was run the test if/when connected :-)

> 
> However, for what it's worth here's a link I found to a discussion about
> setting the firmware inactivity timeout for a WD enclosure.  In this
> thread setting the timeout from Linux didn't work, but the thread is 11
> years old so maybe you can have better luck with your current
> enclosures.
>    https://community.wd.com/t/my-book-essential-2tb-going-into-stanby/497

I'll have a look, thanks.

> 
> (If you can get sgparm to update the timeout dynamically, you could
> leave a normal default most of the time but disable the timeout during a
> long self-test run...)

I see the idea, yep.

> 
> If you do investigate that, let us know how it goes.
> 
> 							Nathan
> 
> p.s. This is unrelated to the timeout issue, but have you tried the
> smartd.conf line without the "-T permissive" option?

In the past, yes. It corrected some other problem I have forgotten :-)

It seems that every time I solve one problem with these disks, I get a 
new problem to solve, when I get tired of seeing the new one. A few 
months for each...

-- 
Cheers / Saludos,

		Carlos E. R.
		(from 15.2 x86_64 at Telcontar)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <https://listi.jpberlin.de/pipermail/smartmontools-support/attachments/20210507/668654ed/attachment-0001.sig>