Unable to restore LUNs with failed OS
Posted: Fri Oct 25, 2013 10:36 pm
I have observed 2 different failure types, virtual drives with T2 SSD Cache, and LSFS
To simulate an OS failure I uninstalled Starwind, reinstalled starwind
1) Created a new target
2) Add device
3) Hard Disk device
4) Virtual disk
5) Use existing
If the virtual disk had T2 Cache attached to it, it fails to create the disk/restore the previous img. It’s almost as if it is looking for the cache file to be right next to the img file but cannot find it so it fails. In my view the point of having SSD cache is to have the cache files on an SSD and the img file on spinning disk. I have noticed during the creation process of an img with SSD caching it seems like the expected practice is to place both files on the same HDD/SSD media. But my view would be if I had placed the img on an SSD why would I need T2 caching? The reason to have T2 caching on an SSD is to speed up the HDD, is it not?
The 2nd failure I noticed was "use existing" on LSFS files. Everything works fine except if you move the file LSFS to another directory or change the drive letter or anything it seems to fail when re-attaching.
While I have not tested LSFS with a T2 cache, I assume it would fail just like the img file with T2 cache
Flexibility needs to be added to the T2 cache association, it’s a cache file it should not be that critical to attach or unattach the file from the parent img/LSFS. It needs to almost be an independent item, what if a cache drive fails from heavy usage? It’s fine with me that the parent img/LSFS has no caching it’s not the end of the world and is fixable, but it seems as it is now should the SSD’s fail they would take the parent img on the HDD with it, even if the HDD was still healthy, I would rather it remain active then to take it with it.
To simulate an OS failure I uninstalled Starwind, reinstalled starwind
1) Created a new target
2) Add device
3) Hard Disk device
4) Virtual disk
5) Use existing
If the virtual disk had T2 Cache attached to it, it fails to create the disk/restore the previous img. It’s almost as if it is looking for the cache file to be right next to the img file but cannot find it so it fails. In my view the point of having SSD cache is to have the cache files on an SSD and the img file on spinning disk. I have noticed during the creation process of an img with SSD caching it seems like the expected practice is to place both files on the same HDD/SSD media. But my view would be if I had placed the img on an SSD why would I need T2 caching? The reason to have T2 caching on an SSD is to speed up the HDD, is it not?
The 2nd failure I noticed was "use existing" on LSFS files. Everything works fine except if you move the file LSFS to another directory or change the drive letter or anything it seems to fail when re-attaching.
While I have not tested LSFS with a T2 cache, I assume it would fail just like the img file with T2 cache
Flexibility needs to be added to the T2 cache association, it’s a cache file it should not be that critical to attach or unattach the file from the parent img/LSFS. It needs to almost be an independent item, what if a cache drive fails from heavy usage? It’s fine with me that the parent img/LSFS has no caching it’s not the end of the world and is fixable, but it seems as it is now should the SSD’s fail they would take the parent img on the HDD with it, even if the HDD was still healthy, I would rather it remain active then to take it with it.