Windows spins up and down disk even when ''-n standby'' is used

[Francisco Guindos]

When the -n standby flag is used to prevent smartctl (and smartd) spin-up the disk, this condition is detected but, anyway, disk is spun-up.
Tested in Windows 7 SP1 64bits, smartctl 6.3 2014-07-26 r3976

[Francisco Guindos]

Screen capture showing disks spun-up

[Christian Franke]

Note that the Windows point of view may differ from actual device standby mode because the device has its own standby timer.

Which DiskPowerStatus tool is used here?

Please provide output of smartctl -r ioctl,2 -n standby -i sdX for a sdX which is in standby mode. Use a plain text(!) attachment, avoid screenshots.

[Francisco Guindos]

You have the reason, yes. Windows (Win 7 SP1 x64) point of view fooled me. When smartctl access the disk in standby, it goes on in standby state but Windows thinks it has been activated. I was a fool believing in Windows. I can only say sorry to bother you and promise not to believe in Windows again.

I used a DiskPowerStatus program that I wrote myself. I could sent it to you (and I will do if you want to), but now that I saw it only shows the Windows point of view and not the actual device status, I think it is of little value.

I got the log you asked, but I think that now it is not needed.

Having said that, why did I hear the spin ups and downs when I used smartctl or smartd?

I have conected the PC to a watt-meter and open the case to feel the disk spinning on my fingers and now I think I know what is happening: it is a collateral effect caused by a faulty Windows 7.
When a smartctl is used on a disk in standby, Windows mark it as active and, if there is no other activity on it, starts its count down to send it to stand by again. When the count down ends, Windows 7 send to standby a disk that already is in standby and it is done spinning up and immediately down the disk.
It is an odd behaviour of Windows 7 that breaks the really "smart" work of smartctl. I can't check if this is corrected in Windows 8 or 10 and I don't know if you think it worths the effort to code a workaround, but if you take this way, you can count on me as a beta tester. I think the way should be to ask Windows if it thinks disk is in standby (that's the only thing my DiskPowerStatus does) before asking the actual state to the disk.

[Christian Franke]

Some RAID capable drivers (like Intel RST) return BusTypeRAID in STORAGE_DEVICE_DESCRIPTOR also for non-RAID drives. In this case, smartctl calls SMART_GET_VERSION to detect device type ATA/SATA. This I/O-control may spin-up the disk (without need). This detection is not done if the device type is specified with -d TYPE option.

Please retry with -d ata option added to smartctl command line. If this fixes the problem, close this ticket to "worksforme".

[Francisco Guindos]

I tried the -d ata option getting the same result: smartctl does not spin up the disk if it is in standby, but it makes Windows 7 initiate a new disk idle timer, and once timed out, it (Windows) spins up and down the disk.

I attach smartctl logs and a report with a chronogram and my test environment.

[Francisco Guindos]

smartctl log of the three times it is used in my test

[Francisco Guindos]

test report with chronogram

[Christian Franke]

Please test whether the problem could be reproduced with a ​recent build which includes r4283 (see ticket #677).

[Francisco Guindos]

I have tested a recent version (6.5 2016-05-01 r4314) and I can confirm
that the odd behaviour is still happening, though it is the same defect stated in ticket #677.

I have tested in Windows 7 professional. Right now, I have no Windows 10 computer to test it. I think I will update my systems by july and I will be able to test in this new version of OS. I think it is a fail most due to a Windows bug, so it could not happen in the new version.

I have some news. I run a command line script to test the bug and the commented bug occurs only if I run it in a shell with administrator privileges (Run as administrator), not when run as normal user.

I attach the script I use to test the bug. This uses DiskPowerStatus.exe, but can run without it. Also, the log (commented).

[Francisco Guindos]

Script I use to test the bug

[Francisco Guindos]

Log file with a few comments