In a previous article, I stated that StorageX is multi-threaded. I also spent quite a bit of time discussing why I consider this fact to be (mostly) irrelevant to the administrator who is using StorageX to perform his file system migrations. What the user of StorageX really wants is for StorageX to do its job as fast as possible: when he is doing a baseline copy, he wants StorageX to fill his network pipe and move the data as quickly as possible, and when he is cutting over to his shiny new NAS hardware, he wants StorageX to do the final incremental copy within his allotted cutover window.
As I mentioned in my previous article, the techniques StorageX uses to fill the network pipe during a baseline copy are very different from those used to find changed files as quickly as possible during an incremental copy. In this article, I will focus on baseline copies.
Continue reading StorageX is fast (baseline copy)
On several occasions, I have been asked a question that is straightforward to answer, but where I’m left with an uneasy feeling about why the question was being asked in the first place. For example, about a year ago I was asked, “Is StorageX multi-threaded?”
That’s a seemingly reasonable question, and a correct answer is easy to give: yes.
I suspect the person who asked the question would have been happy with that basic answer. He would have understood it (“yep, they have multiple threads in their program…that’s good, right?”) and he could easily convey the answer to whoever asked it of him. Most likely the question originated with a piece of marketing collateral for a competing product, touting how the product is “multi-threaded so that it scales to the available hardware” or some such seemingly wonderful claim.
Continue reading StorageX is multi-threaded (and more importantly, it is fast)