Re: smartctl 6.2 for windows, bug: reading data from wrong device?

Christoph Gensler wrote:
> Hello
>
> I have installed smartmontools on windows 7 ultimate 64bit yesterday. 
> Very useful, but I guess there's a bug:
>
> I have many disks attached. Besides others, there are three SATA disks 
> (F:, G: and H:), one (F:) connected to main board, and two connected 
> to an AUSS U3S6 controller. All of them are no system disks.
> Drive F was installed in january 2013, drive G is about 3 months old, 
> and drive H: was installed today, just some hours ago. (This is 
> important, so we have a criteria to distinguish them even in smart 
> selftest log lists, as you can see later on.)
>
> smartctl -i <driveX>:\ works fine on all three drives. All of them are 
> different types, and each type gets displayed properly, as expected.
>
> But smartctl -l selftest <driveX>:\ only gives back log information 
> from drive F: and drive H:, drive G: is not available - better to say: 
> requesting information on drive G: always seems to show the log from 
> drive H:!!! Remark: both of them are attached to the ASUS U3S6 
> controller.
>
> I proved:
> -- smartctl -A <drive> reports 855 power-on-hours for G: and 5 for H: 
> - both values are correct.
> -- smartctl -l selftest <drive> always reports selftest logs from 
> drive H:, even when called with drive G: Both logs are identic 1 by 1, 
> regardless of G: or H: is addressed.
> -- Starting a short selftest on H: and executing smartctl -l selftest 
> <drive> will result in displaying a running selftest on both (!) 
> drives, H: and G:, both completed with same percent value.
> -- Starting a short selftest on G: and executing smartctl -l selftest 
> <drive> will result in displaying no running selftest, neither on H: 
> nor on G:
> -- Any change in log of H: seems to be "mirrored" 1 by 1 in log from 
> G:, if you would trust smartctl -l
> -- Drive F: seems to be handled correctly any time, no weird displays 
> seen so far
>

When drive letters are used as device names, smartctl relies on the 
(undocumented) fact that Windows routes pass-through I/O controls to the 
underlying physical drive ("\\.\PhysicalDriveN") if a logical drive path 
("\\.\X:") is opened.

Using physical drives instead may work better: sda, sdb, ..., or pd0, 
pd1, ..., see man page. Try "smartctl --scan".

If a driver does not support IOCTL_ATA_PASS_THROUGH, smartctl tries 
other I/O-control as a fallback. In this case, e.g. SMART logs 
(IOCTL_SCSI_MINIPORT) may be read via a different I/O-control than SMART 
data (SMART_RCV_DRIVE_DATA). This may explain why the wrong drive is 
accessed for some functions only.

Try "smartctl -r ioctl,2 ..." for debug output. It prints the 
I/O-controls used.

Thanks,
Christian


------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk