Hard Disk Monitoring

Hello,

if Hard Disk Sentinel (HDS) is used to manage a RDX media (e.g. Tandberg, HP, Imation) it will cause loss of data.

Situation:
An RDX drive (tested: SATAIII or USB3.0) with inserted RDX media is connected to Hard Disk Sentinel.

Problem:
HDS will not show any informations about the RDX media. If selected some functions of the menu "Drive", e.g. "Surface Test", there will be a short delay and a error message "No access to the selected media". In that moment, data on the inserted RDX media is LOST. To clarify: Data loss happens in that moment if HDS will check inserted RDX media without start of any surface test.

The RDX media is no longer readable after this issue and even windows won't format it. Only the formatter in the Utility "RDX Manager" is able to format this media again for further use.

Best regards,

hdsXpert

Hello,

Thanks for your message and excuse me for the possible issue, this sounds really shocking.

I can confirm that generally such should never happen. No other user reported similar, even with different type of RDX devices (just checked the tests and reports received from users in the years about HP, TANDBERG, DELL RDX devices with USB and SATA connection where applicable and with devices in the range of 320 GB - 1 TB).

The issue you wrote also sounds weird. I can confirm that Hard Disk Sentinel (during both the normal periodic status detection and when the Surface test window opened but before starting any test) does not access the disk surface (data sectors), especially does not attempt to write (or clear / alter) any kind of data on the devices.

> HDS will not show any informations about the RDX media.

Yes, I'm afraid this is known - and somehow normal. But not really related to Hard Disk Sentinel, this is a limitation of the device itself.

Personally I expected that (as for example with LTO devices, industrial memory cards in addition to hard disks / SSDs) status informtion can be detected with at least some RDX devices. So Hard Disk Sentinel now attempts to detect the status - but according all tests (and reports from users) yes, this always fail, the RDX devices provide absolutely no status information. Which is (in my opinion) a big disadvantage, as considering the value of these devices (and value of data may be stored) we'd need to have complete status information to confirm that the data is safe.

So Hard Disk Sentinel attempts to detect status information (just like for other devices like hard disks, SSDs, etc.) but this detection should be safe enough to do not cause such problems or compatibility issues. This is especially true when SATA connection used: there Hard Disk Sentinel does not attempt any special detection (which may used for USB devices), just detects the device model, its features - and as usually these devices do not support self-monitoring function, it does not perform any further access to RDX devices/media.

Would be nice to investigate the situation, examine what happened exactly - to determine all possible ways about how to avoid it. Maybe related to some combination of OS, RDX device, controller, driver, motherboard chipset, Hard Disk Sentinel version and so.
So please use Report menu -> Send test report to developer option when the appropriate device connected. The best would be if it's possible to send different reports when different connections used.

Sorry for the troubles, I'd do the best to examine, investigate and improve the situation to prevent issues.

Hello,

thanks for your quick answer.

Yes, I was also quite surprised about this incompatibility consequences. It seems, that MBR of RDX media will be destroyed in this case.

In short: Test was done with a very usual PC, based on Core i7 / 16 GB RAM / Asus Mainboard. Situation was even tested with the Windows PE version of HDSentinel where the effect ist the same. RDX Media was 500 GB and 2 TB, firmware of the drives has been updated to the latest version.

I already thougt that information about RDX media in HDS will be difficult because of the proprietary RDX technology. So far no problem, but working surface tests would be helpful.

In the next weeks I will investigate testing, e.g. will test it on some more PCs and will send you mentioned report.

However, Hard Disk Sentinel is my "swiss knife" for drives and I like much to work with this software.

Best regards,

hdsXpert

hdsentinel wrote:I can confirm that Hard Disk Sentinel (during both the normal periodic status detection and when the Surface test window opened but before starting any test) does not access the disk surface (data sectors), especially does not attempt to write (or clear / alter) any kind of data on the devices.

That is not 100% true. The JMicron RAID library (which HDS uses) writes to a single "unused" sector on EVERY disk connected to your PC. That is how it searches for (and communicates with) JMicron RAID chips. I know this because I have reverse engineered the official JMicron RAID manager software so I could write my own software to detect the state of my RAID 1 array. The JMicron RAID library first tries to locate an "unused" sector (not always the case! the unused sector detection code is very simple/dumb), backs it up, overwrites it several times (to communicate with the JMicron chip) and restores it afterwards. If something goes wrong and the restore never happens and if that unused sector was actually used then something will have been corrupted. I am not sure if that is the case here but I thought I should let you know.

Yes, this is absolutely true: Hard Disk Sentinel uses the official JMicron RAID library (provided by JMicron) to communicate JMicron eSATA/USB RAID controller chips and access status information.

But exactly to prevent problems, this external module never started unless Hard Disk Sentinel finds a device (a JMicron RAID controller) which can be accessed - as then it starts the JMicron-specific detection in order to communicate with the controller.
Yes, it may access other drives too, I'm afraid I have no control over it, as the official communication library is provided by JMicron and could not be changed/modified to work differently.

So if I understand correctly, then the "problem" was that the JMicron-specific detection is caused troubles in your case, so problem may happen when both RDX device and JMicron RAID used together. It would be excellent if you can use Report menu -> Send test report to developer option, as then I can check the "raw" response of both devices and can improve the detection - or at least disable JMicron specific detection completely in this case for security purposes.

Hopefully we'll get an updated library with JMicron and this may improve/fix the situation.

Sorry for the troubles and thanks for increasing attention to this special combination, really interesting and I'd do the best to avoid conflicts and improve compatibility.