|
Qstar MastarMindMastarMind handles HSM differently from the rest. It's not a bad implementation, but we aren't completely convinced of the integrity of its primary and secondary storage coupling.QStar's MastarMind treats the local hard disk as a cache for the MO pool, which is conceptually normal. However, this appears to the user as one contiguous file system with the MO disk being the main media and the hard drive serving as a cache for recently used files. This tightly couples the secondary media with the local hard disk cache. Migrations from the clients aren't made directly to MO, but to the server hard disk cache first. Installation and configuration were a bit more difficult than most. The documentation was plentiful, but wasn't much help in solving common configuration problems. It seemed to be written as a reference manual for the experienced QStar administrator. It was only after a couple calls to technical support that we realized we couldn't use our current volumes for HSM. That's right. We were forced to tar up all the data on our intended HSM volume and store it on another server. When using QStar's utilities, we had to recreate the volume before the software could manage it. This creates a file system called an Integral Volume that integrates the cache disk with the MO pool. Then we could mount both resources as one HSM volume. Only then were we able to repopulate the file system and use the HSM migration. All other software allowed us to use our current partition and simply define a migration path. By forcing a replication to MO, we made sure our files were completely safe. Since it was already replicated on the MO media, destroying the ha rd drive cache was not dangerous. After reconfiguring the partition, the software rebuilt the stub files on the magnetic disk. In a matter of time we were back in business. Back to Review Menu. |











