New Linux Tool - HDDSuperTool
- Thread starter maximus
- Start date
Quick update: There is a reason that no one has done this before. AHCI is definitely not easy, at least not for what I am doing. I have found that different hardware can react differently. And there is no guide on how to do this, other than technical documentation. I have just now got something that I think is slightly stable (at least as stable as nitroglycerine).
So what is the first thing I had to try with it? I managed to run two instances at the same time reading two separate drives. And they both read at the same speed as they would by themselves (but there was no writing, only reading with data being thrown away). Not that I would ever recommend it (because it would probably be a really bad idea), but there may be the possibility to run a couple recoveries on the same computer at the same time, assuming you like to take chances.
So let’s say I can make this work and write a usable cloning utility that can perform soft resets on IDE and both soft and hard resets on AHCI, with the option to perform power cycles with an external relay. It would have a logging ability such as ddrescue (not the same but perhaps with the ability to import a ddrescue log), and also a very similar algorithm to start with. So is there a good market for this? I have every intention of making a dos style GUI for it (similar to MHDD or testdisk), but would probably make it work at the command line level first. Although I am not sure I would try to market a command line version, probably wait until the GUI version. I might make a free teaser command line version that would have about the same functionality of ddrescue when used with my passthrough patch.
I currently have a full time job, so I am doing this in my spare time. I would love to make this software and possibly my own data recovery service my full time job, but I would have to start seeing a big enough return before I could just quit my regular job. There is a BIG gap between the current software only tools (such as ddrescue) and the very expensive hardware tools. I am looking to fill that gap. So would there be a good demand for something like this? It could be a good secondary tool for the professionals to help free up the expensive hardware tool for the harder recoveries, and perhaps a starting point for those who can’t afford the big tools. Although it may spawn a new group of wannabe data recovery specialists.
So what is the first thing I had to try with it? I managed to run two instances at the same time reading two separate drives. And they both read at the same speed as they would by themselves (but there was no writing, only reading with data being thrown away). Not that I would ever recommend it (because it would probably be a really bad idea), but there may be the possibility to run a couple recoveries on the same computer at the same time, assuming you like to take chances.
So let’s say I can make this work and write a usable cloning utility that can perform soft resets on IDE and both soft and hard resets on AHCI, with the option to perform power cycles with an external relay. It would have a logging ability such as ddrescue (not the same but perhaps with the ability to import a ddrescue log), and also a very similar algorithm to start with. So is there a good market for this? I have every intention of making a dos style GUI for it (similar to MHDD or testdisk), but would probably make it work at the command line level first. Although I am not sure I would try to market a command line version, probably wait until the GUI version. I might make a free teaser command line version that would have about the same functionality of ddrescue when used with my passthrough patch.
I currently have a full time job, so I am doing this in my spare time. I would love to make this software and possibly my own data recovery service my full time job, but I would have to start seeing a big enough return before I could just quit my regular job. There is a BIG gap between the current software only tools (such as ddrescue) and the very expensive hardware tools. I am looking to fill that gap. So would there be a good demand for something like this? It could be a good secondary tool for the professionals to help free up the expensive hardware tool for the harder recoveries, and perhaps a starting point for those who can’t afford the big tools. Although it may spawn a new group of wannabe data recovery specialists.
pclab
Moderator
Hey
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.
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.
Just thinking how easy this would be to adapt to an open source hardware imager. a Low cost Linux SBC, a case.. I think having a range of products could help make it your only job, sort of like different levels of product. Then you could hone a lean Linux distro to suit perfectly.
I have thought about bundling it with hardware, but that complicates things. First, I would be relying on being able to get certain hardware in quantity. Any change in hardware availability would be an issue. Second, most of that cheap Linux hardware only has one SATA port if any, and no IDE at all. Third, that drives up the cost and also consumes more of my time as then I would have to physically set up and package it to be shipped. As software only the end user can use whatever computer they have available, assuming that it has the ports they need and can run the version of Linux needed (and assuming that I can make it stable on all hardware).
Now if I could figure out how to embed some of the code in the hardware to make piracy extremely difficult then I may consider it. But I have not been able to think of a way to do that. That would most likely require specialized hardware. And unless it could be made unbreakable, it is not worth the time and effort.
I am hoping to have a testing version ready soon. Along with seeing how it handles bad drives, I also need it tested on good drives to make sure it is stable. The more different computers it can be tested on the better. Right now my greatest concern is stability across different hardware.
Now if I could figure out how to embed some of the code in the hardware to make piracy extremely difficult then I may consider it. But I have not been able to think of a way to do that. That would most likely require specialized hardware. And unless it could be made unbreakable, it is not worth the time and effort.
I am hoping to have a testing version ready soon. Along with seeing how it handles bad drives, I also need it tested on good drives to make sure it is stable. The more different computers it can be tested on the better. Right now my greatest concern is stability across different hardware.
Speaking of bugs, I would like to get one thing out of the way now. If you system has more than 4GB of ram is it highly recommended that you use a 64 bit version of Linux. The reason for this is that I perform some crazy voodoo magic to get access to physical memory in the 32 bit range (required for IDE). During this ritual much ram may be sacrificed. Don't worry, the ram is later released from my spell and placed back into the wild unharmed. When there is over 4GB a 32 bit OS seems to like to always pick addresses that are out of the 32 bit range. This actually also can happen when there is only 4GB of memory (the fact that a system with only 4GB of ram can have a physical memory address above the 32 bit limit does not compute! :shock: ). When running a 64 bit OS my voodoo magic is much more successful. I cannot overcome this limitation with a driverless application. I must rely on my powerful magic :twisted:
Just as a though, if you did want to hardware "link" the software, Banana Pi (http://www.banana-pi.org/) is making some pretty powerful little boards and should be no issue to get a quantity of them. Only thing it's lacking is a second SATA port or USB 3.0, but I'd guess the next revision will have it.