I will keep this short and sweet. This message is directed at Dimitry Postrigan, the author of MHDD (among other things.)

I [professionally] fix several hundred PCs every year, for a major retailer. I had MHDD on one of my tool discs for a few years. I'm not sure why I added it to my disc, because I can't recall anyone ever recommending it. However over a year ago, I tried MHDD and was [pleasantly] shocked by the program. I've come to see it as one of the best diagnostics (of any kind) I've ever used, in ten years of full-time PC repair.

I've always relied on the hard drive mfr's diagnostics, but occasionally they don't work at all or perform poorly or perhaps they don't exist/can't be found. Using MHDD, I can quickly determine when a drive is beyond repair, repair/remap a couple bad sectors, or benchmark the performance of a drive to help a customer decide if a drive should be replaced or not.

If there is any criticism of MHDD, it's that MHDD is hosted on a brain-dead OS: DOS. Two weeks ago, I tried to test a laptop drive connected to my PC via a USB/SATA adapter, but the Panasonic USB driver hung up right in the middle of detecting the USB device. Which brings me to to my request: is there any way you would reconsider resuming development of MHDD, in order to port it to Linux ? You might even consider releasing the source code for MHDD under one of the open-source licenses and permit others to do the work of porting it to Linux, if you're not interested.

Anyway, hosting MHDD on a modern Linux system would offer several advantages/enhancements:

1. ongoing, state-of-the-art driver support for all the different controllers/devices on the market
2. a modern host OS, which directly supports multitasking and other programming abstractions
3. a superior programming/development environment

A recent Google/Freshmeat/Sourceforge search suggests there are no native Linux-based drive diagnostics/utilities. Even though I've been a professional programmer for nearly thirty years, I don't have the requisite Linux programming expertise, to ensure that this exercise is even feasible. However, if the underlying technology found in MHDD's source code isn't proprietary to your other activities/projects, releasing the code to the open-source world (eg., via Google Code) might put the port in the hands of those willing and able to pull it off. That is, assuming you're unable/unwilling (of course, due to time-constraints) to attempt it yourself.

In any case, I hope you find this idea worthy of your consideration and if you haven't already thought about it, please take some time to "try it on for size." Thank you for your attention and continued success in your endeavors.

Respectfully,

Jet Wright

A few comments...

FYI, don't expect him to read your post automatically - he has said several times that he doesn't have time to do read every posting here. If you want to be sure that he'll read your post, I recommend that you PM him with a link to this thread.


That's one of the big advantages of the MHDD software too!!

DOS does not force a program to use storage drivers and does allow access from user programs(e.g. MHDD) directly to I/O port addresses. Therefore MHDD can access any I/O port address, to directly access the registers in an HBA register set and program them. This direct accessing of the HBA cannot be done reliably or safely, at the same time as an OS driver is controlling the HBA.


As soon as you introduce OS drivers into the I/O stack for any diagnostics, you are leaving yourself open to misdiagnosis of the hardware, due to problems (or lack of functionality etc.) in the drivers. Using OS drivers is not risk-free. You have seen this yourself, with the Panasonic USB driver which you described! I've had to help HBA manufacturers fix their drivers (and built-in firmware) before, so I know some of the problems they can have, including coping very badly with defective drives, and having their own bugs, which wrongly make you think that a drive is faulty, even when it isn't.

When writing diagnostics, you typically don't want multi-tasking involved, when you're performing any timing-senstive operations. You list this as if it's a positive. For me, as someone who is also involved in writing diagnostic software, it's a negative. Also, MHDD could not easily access the I/O port addresses directly (as it does now), running as a user program on Linux.


Of course it's up to Dmitry to decide, but IMHO I fear you may be underestimating the extent of the changes necessary to a low-level program like MHDD, to have it use any modern underlying OS and still reliably and completely do what it does today, using DOS. If MHDD is rewritten to run on Linux, that software cannot replace the great simplicity and lack of ambiguity in the results, that MHDD (on DOS) provides today

As Vulcan indicated, this is highly desirable.

_________________
You don't have to backup all of your files, just the ones you want to keep.

Condescending, but accurate. You were okay up to this point. However, I will reemphasize I can not underestimate any exercise that I explicitly state that I'm uncertain of its feasibility. You seemed to be convinced that an attempt to port MHDD to Linux will fail. That suspicion might be true, but it can only be proven with an attempt. At minimum, an effort to study the exercise is worthwhile. Clearly, you wish to have no part of that effort. So be it.

A feasibility study is only possible if Dimitry chooses to releases the source code. There are foreseeable obstacles here, among those:

1. there is proprietary code embedded in MHDD, which prevents it from being released to the open-source world
2. this exercise has already been explored and dismissed as infeasible
3. language could be a show-stopper: MHDD might be documented in Russian, fine for a team of Russian programmers, not so good for the rest of us; one simply can't feed assembly-language source files through Google Translate

Again, so be it.

I tried hard not to be condescending. It's clear that you took lots of effort to write such a good posting. However as you yourself said, you do not have Linux programming experience, so you are, by definition, talking from a position of limited knowledge in this specific area. It's a shame that you still took my posting that way

IMHO, some of your comments miss the whole point of MHDD and its lack of reliance on OS drivers. But that's fine, we have different views.

Since (among other things) I write diagnostic software (and have a patent in this area), and I've been involved with fixing Linux drivers, I thought I had something to add to the conversation. I'm not "convinced" (your description, not mine) that porting MHDD to Linux would "fail" (your description, not mine). I also did not say that I wished to have "no part" of porting (why are you putting so many words in my mouth, that I didn't say?). It's a shame that you seem to have misinterpreted much of my posting.

However based on my experience, I do believe that the result of such a porting, when using Linux drivers as you suggest, would lose many of the benefits of the current DOS version. Your posting did not address this point, so I did. That's all

As we have both said, it's up to the author to decide what to do

Nothing proprietary about ATA commands

_________________
You don't have to backup all of your files, just the ones you want to keep.

Does MHDD use Vendor Specific ATA commands?

_________________
A backup a day keeps DR away.

Have you ever used the program?

_________________
You don't have to backup all of your files, just the ones you want to keep.

I don't understand the relevance of your question.

I am aware that you can manually enter VS commands via MHDD scripts, but how would you know whether MHDD does this internally, especially as it accesses the drive directly, without going through BIOS?

_________________
A backup a day keeps DR away.

And why would people need disk scanner for linux?

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.

I ask because I'm unclear as to which of MHDD's functionality you think would require vendor specific commands?


I'm not sure what you mean here. Sure, MHDD can set the ATA command registers to whatever you tell it to. If you happen to know some vendor specific commands, you can send them. There is nothing proprietary about how this works.

_________________
You don't have to backup all of your files, just the ones you want to keep.

I have plenty of experience with Linux diagnostic software :O) and find the open source drivers/manuals refreshing. Porting should not be so painful but who has the time? :O( not me

_________________
All went well until I plugged the drive in.

Hi everyone,

MHDD source code now belongs to Seagate, therefore I guess you would have to ask Seagate about it. I have no right to publish source code or continue development, unfortunately...

_________________
Dmitry

Greetings,

I'm inclined to agree that this type of tool wants low-level access to its target, with no interference from an OS/drivers. But, does it really need it? Given that disk drives, nowadays, are so (relatively) high-level (I wrote a couple of disk drivers [Unix] pre-1975), there might be merit in considering something along the OP's quest. [In the spirit of MHDD (but not the letter).]

[I retired ~15 years ago, but ...] For grins (and to keep the cobwebs out of my brain), I write some code every few years. A recent hack was a "transfer-rate test". One of its functions can be made to mimic the crux of MHDD's SCAN and MAKELOG capabilities, but in a Unix/Linux environment. The resulting data is surprisingly accurate, and useful.

For example (testing a Hitachi HDS5C3020ALA632 [2TB]):
xft -uu -b128k -n320k -s80g /dev/sdX > 5K3000_80g.txt
will time 320k consecutive reads (128k each [40G worth]) starting at offset 80G, reporting each in units of microseconds.

In an initial attempt to minimize "disruptions", I've run it under Knoppix v6.2 in single-user, terminal mode (runlevel 1). The only hiccups I've seen are a ~1 millisecond pre-emption every 2-3000 samples (as evidenced by a "unexpected" slow sample, followed by a couple of "too fast" samples (cached read-ahead coming through at 3Gbps speed). I'm confident that even this minor glitch can be eliminated by doing a major purge of the background/daemon processes.

For anyone curious, I've attached a few KB snippet of the output, which does include one of those "hiccups" (line 784).

I offer this as a (possible) "proof of concept" to encourage someone else to consider pursuing this (I intend to stay retired ). But, if anyone wants to play with "xfrtest", I can make an executable available. (see attached xft_usage.txt)

--UhClem