From: <ch...@ge...> - 2013-11-23 21:24:17
|
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 I guess, smartctl has some difficulties in addressing the correct disk on some, but not on all operations - at least identifying the drives works correctly. I'm not sure, but drive H: is a replacement of another disk, that took place today. Before I changed the disks, I also used smartctl for some tests, and I'm not sure if drive G: was also "invisible" with the *old* disk installed. Please, feel free to request some more detailled information if it can help to debug. I'm willing to assist in debugging, but I refuse reading mailing lists and stuff, so please get in direct contact with me, if required. As I can see from your copyright, the name "Christian Franke" reads very german - as I'm german, too, please let me know if I can avoid writing all this in english. And as I'm developing software since nearly 35 years on my own, try adapt your level of requests to this, please - I'm no newbie. With regards Christoph Gensler -------------------------------------------------------------------------------------------- Christoph Gensler IT-Support mailto:ch...@ge... |
From: Christian F. <Chr...@t-...> - 2013-12-02 19:23:35
|
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 |