New Linux Tool - HDDSuperTool

M

maximus

Member
I have a trivia question to ask. And by trivia I mean that I don’t know the answer.

If a computer has 4GB of ram, that should be memory addresses from 0x00000000 to 0xffffffff, which is in the 32 bit range. So how is it possible that it can have physical memory addresses in the range of 0x1xxxxxxxx? Seriously, how the hell can that happen?!?! What kind of twisted evil is that! :shock:
 
M

maximus

Member
pclab":259vvute said:
I think that if it works, you will have market. I believe, as you say, that every lab want's/needs more imagers and getting a DDI or a PC3K card, etc to work as imager is too much $$$.
So if you can develop such a tool that really works (no bugs, time to time updates, etc) you will get a market.
Of course, the value of the tool will also make the difference. There's no point of develop a 1500$/2000$ tool to work as an imager when we have a DDI RapidSpar that costs 2000$ but comes from a very knowned company.
Keep it up.
Click to expand...
So what would a tool like this be worth? I am thinking the $100-500 range. And while I may like to currently state in the license agreement that it can only be used on one computer, it will likely never have the ability to check that so I may as well say you can use it on 3 or 5 computers and charge accordingly. I know it is very hard to judge without the tool actually being available yet, but try to base it on the following facts (and also assume that it will work). The most basic version that I would try to market would have a dos looking interface such as MHDD or testdisk, and would likely only work with the keyboard and not the mouse. It would have logging and would be able to resume. It would have an algorithm similar to ddrescue 1.19 or later with a fair ability to skip out of a bad head quickly to get the most good data first. And of course the kicker, to be able to actually perform soft resets using a user adjustable timeout, and with AHCI also the hard reset. It would also have the ability to control an external relay via USB for power cycles. There would be some small physical wiring setup for the relay system to work. I can currently control a USBmicro U451 that has two relays, and have just received some cheap generic USB controlled relays to test. So if it did not recover after a reset, or exceeded a timeout, or set the device fault bit, it could be power cycled automatically.

One downside is that the user must run a compatible version of Linux, even if on bootable media. I am sure I could include the ability in my software to block a drive/port on an installation, but it would need to be done manually when using bootable media. Some instructions could be provided on how to do this, but would still require the user to be capable of doing so. And honestly if the user can’t do that, they should not be attempting data recovery using my software.

Another downside is the required physical setup for power cycles. Instructions could be provided for this also, but I may also consider selling a separate kit (computer power supply and USB relay wired up ready to use) as an option, for an additional price of course.

So that is the base idea, what would that be worth? Now consider that future versions, perhaps requiring a license upgrade, could possibly do something crazy like file based recovery. I have already done file recovery on NTFS using ddrescue and custom software so it is not out of my reach (ddrutility can recover the MFT and the bitmap, which are both files, and I have also recovered whole directories where testdisk would fail to do so). In the big picture I would love it if I could get an agreement with someone like R-Studio to set up my software as a plug-in. Always think big!
 
pclab

pclab

Moderator
Well. I think that would be a good price range, especially if you add some kind of hardware on it.
Of course, that if you don't put a system to control the number of machines that could work, it will be bad for you. How about any kind of bootable flash drive with you software in it and blocked to copy or something?
 
M

maximus

Member
pclab":133w1xo4 said:
Well. I think that would be a good price range, especially if you add some kind of hardware on it.
Of course, that if you don't put a system to control the number of machines that could work, it will be bad for you. How about any kind of bootable flash drive with you software in it and blocked to copy or something?
Click to expand...
I just thought of a way to lock it to a machine. I am actually doing it now when the license installs, so the basis of the code is already there. I was planning on just giving out the licenses in serial number form. But I could easily make it so the program provides a code specific to your computer, and then I would provide the license file in place of the serial number. I have seen software like that before. The only issue would be that if the computer hardware failed, the end user would have to get another license to use on a different computer. And if the user just wanted to move it to a different computer it would be hard for me to know that they were not just saying that to get another license. But it would be a starting point.

If there is a way to do specialized code on a USB I would be all for it. But if it can just be hacked by someone in 2 weeks then it would not be worth it.

I have also thought about using a server for authenticating an installation, but I don't know how to implement that at this time, not to mention that requires upkeep on my end. Plus that would require the end user to have the computer connected to the internet. Lots of things that could go wrong with that method.
 
Jared

Jared

Administrator
Staff member
You asked about price range before. If you could create a software tool with imaging functionality comparable to DDI (obviously without all the advanced stuff like imaging by head map) it'd easily be worth a solid $500. Even just to add more imaging stations in a lab that already has these tools and just needs stations for the easy ones with a few bad sectors. But, it would have to be fast and reliable to justify it. That's why using specific hardware might be a better route to ultimately take. So you can know for sure how well it works with the particular controllers on board and avoid hardware specific issues.

Also, by doing it as a hardware/software solution you could eventually add in a small relay board that could power cycle the source drive when it goes unresponsive. Plus hardware/software adds a perception of higher value than a software only option even though the hardware might only cost $150-$200 ultimately. Perhaps could sell it both ways, an all-in-one hardware/software solution for $600 and a software only $300 (not guaranteed to work as well or as fast).
 
M

maximus

Member
I am rethinking the hardware bundle now. If I am going to be using a USB dongle for activation, then I am already doing some sort of hardware that will need to be shipped. Next would be an optional computer power supply and relay board all wired up for use, and might as well do an IDE cable modified to do hard resets. And then if needed, an actual computer system that it is known to work on. This could all be optional, for an extra cost of course, offering different package levels with possible upgrades.

But enough talk about what-if, time to get back to the programming to get a beta test ready. Non of this means anything if it doesn't work like it needs to. Although I am confident that I will achieve it :cool:
 
K

koitsu

New member
Hi maximus,

I began giving hddsupertool a try earlier today (see here for details) and found a few things that could use improving:

1. Better documentation on what the -C / --command flag actually does and maybe a couple real-world examples. The docs here are too sparse.

2. Better parsing/understanding of filenames passed via the -f / --file command. Usually with *IX utilities this refers to a full path. I don't use install.sh because the Linux system I use is boot-from-CD (i.e. read-only /), therefore I use things like ./hddsupertool. I was attempting to do ./hddsupertool -t /dev/sdd -f hddscripts/wd_royl_dump_mod02 and the script kept failing due to not being able to find file good_subroutines. As a workaround I ended up doing cd hddscripts ; ../hddsupertool -t /dev/sdd -f wd_royl_dump_mod02 but that obviously dumped the two .bin files into the hddscripts directory. Hopefully you can see the issue with all this; it seems like "include foo" wouldn't know to do "include hddscripts/foo" in my first example.

3. Proper use of exit codes. Right now the program appears to return exit code 0 even if the device doesn't exist (e.g. /dev/sdd doesn't exist yet because the drive hasn't spun up yet, USB layer still being enumerated, etc.). The problem with this becomes quite apparent when using && or || in a shell to handle error conditions, i.e. hddsupertool -t /dev/sdd -f thing1 && hddsupertool -t /dev/sdd -f thing2. I suggest reading about sysexits.h (available on Linux and BSD) and looking into the EX_* defines that are available per situation. Else bare minimum effort, at least exit with code 1 when an error condition occurs (esp. can't open device/fd).

4. On your site you provide some "helpful tips" that reference using tee and things like 2&>1. Might I suggest mentioning "script" (ex. script log.txt), which saves all input and output to log.txt. The user has to remember to do "exit" when finished (because as said, script spawns a sub-shell).

Let me know if you need any more insights on these recommendations. You'll probably be seeing more of me or hearing more from me in the future given some drives I'm having to work on (I'm a C programmer and speak ATA protocol as well, I'm a UNIX SA professionally and have been a contributing member of the FreeBSD project for some time). Thank you so much for your work.
 
You must log in or register to reply here.
Top