Date: Wed, 17 Jul 2019 19:37:25 -0700 From: Ravi Pokala <rpokala@freebsd.org> To: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, <rank1seeker@gmail.com>, <larry.maloney@hackerdojo.com> Subject: Re: For a first time completed S.M.A.R.T captive test Message-ID: <481465DB-D5EE-4019-A2DB-DBA4D46FE312@freebsd.org>
next in thread | raw e-mail | index | archive | help
Hi Domagoj The "captive" test is blocking -- meaning the drive won't indicate command completion for multiple hours in the case of modern large HDDs -- so the FreeBSD driver will almost certainly timeout before completion. That in turn will trigger recovery mechanisms, which will include a soft-reset, which is where the "Interrupted (host reset)" comes from. You almost always want to do the "off-line" test; that tells the drive firmware to start the test and run it in the background. It will indicate command completion in a second or two, but the test will still take the same amount of time. But in the case of the "off-line" test, the drive is responsive to the host even while the test runs. When the drive receives a command from the host, it will pause the test, service the host request, and then resume the test. I work at a storage company, I've been running ATA self-test for 15+ years, and I've never understood why the "captive" test even exists. *Maybe* there were dedicated drive test systems that had huge timeouts, back in the PATA days? Or even horrible DOS stuff that didn't even have a timeout, and just waited for the interrupt forever? <shrug> In any case, I would simply not bother with the "captive" test modes. -Ravi (rpokala@) <wearing Panasas hat>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?481465DB-D5EE-4019-A2DB-DBA4D46FE312>