Data Recovery Weekly

Came across this, admittedly old, discussion about Storage Spaces http://www.eightforums.com/general-support/15887-storage-spaces-questions.html The fun starts at around post #4, with a real good piece of advice - your setting up a large drive system, read a LOT before committing your data to it for good. Then the discussion touches the Drive Extender briefly. Storage Spaces is not Drive Extender . Indeed it is not. Storage Spaces is arguably more fragile, and undoubtedly Storage Spaces is more difficult to recover once failed. Way more difficult, I'd venture to say. Then, around post #8, virtual machines come up. The common misconception is that recovery from storage system failures can be practiced with virtual machines. You'd better not. Virtual machines are good for modeling and training some normal operations of a storage system, but they are abysmal in reproducing storage behavior in failures. In a virtual machine, all hardware is fail-stop. You cannot simulate b...

Sadly the predictions about people using sub-par hardware to build enormous Storage Spaces configs are gradually coming true. Not that the hardware is bad or faulty per se . It is not just up to the task. Any large storage configuration, except maybe some network-based distributed systems (which are designed to be slow, by the way), requires stable hardware. Even a drive failure rate of one failure per year per drive would still be acceptable. On the disk set of ten or more drives, one failure per drive-year is an annoyance, but one can still expect the system to be able to cope. However, in what we are looking at now, with USB configurations of forty drives or larger, the failure rates are closer to one failure per drive per week. This results in systems where the lifetime expectancy is comparable to the time needed to populate the system with the initial data set. Once the data is copied over, original copy deleted, and original drives reused, whatever lifetime left in Storage Spac...

If you delete a Storage Spaces pool on a TRIM-capable SSDs, the entire pool gets trimmed, as in poof!, gone .

At various times, there was a variety of tools to organize disk space on the PCs running under Windows both native such as Drive Extender (now extinct) in Windows Home Server, Logical Disk Manager (LDM) in Windows 7, Storage Spaces in Windows 8 Storage Spaces, and third party tools like StableBit or DriveBender. Now less than two months after Windows 8 with Storage Spaces is released, it would seem that everything is bad - people on different sites cry that Storage Spaces is buggy and doesn't work. However, surprising as it may be, software developed by Microsoft is more reliable and better tested than any third party tools. By this moment, obviously, Storage Spaces has a larger user base in terms of installations, number of disks, capacity of stored data, and disk-hours online than all the software from different vendors combined for all the time of their existence.

At this moment, the situation with the software prototype is as follows: S can and analysis of four 2 TB disks on the machine with two CPUs take a day to complete and require 6 GB of memory. Adding two more processors can probably speed the process by the factor of 1.5. Although the prototype can successfully recover Storage Spaces configuration on small sized LUNs (approx. 16 GB per LUN), it yet cannot cope with the large LUNs. The prototype is capable of recovering only Storage Spaces volumes with NTFS; as for ReFS, this is still to be implemented.

Based on the first real-world test of ReclaiMe Storage Spaces Recovery we found out that Storage Spaces recovery is generally limited by CPU power rather than memory and disk throughput. Thus, new projected system requirements look like this: no less than 512 MB RAM per disk although there is no minimum CPU limit, it is desirable to have one core per each two disks. While the number of processor cores is less than half the number of disks, adding cores increases performance linearly. We know definitely that if the number of processor cores is equal to the number of disks, adding cores no longer makes sense. In the intermediate case, when one core handles two or less disks, it is impossible to accurately predict what the performance will be in terms of speed gain. S o the system with four cores and 8 GB of memory should cover most needs. In other words, you can still get away with some high-end desktop hardware.

People who want to get back Drive Extender instead of Storage Spaces usually test Storage Spaces using a parity layout. Then they complain that there is no rebalancing, speed is low, and all in the same spirit. However, with all of this testing they forget that Drive Extender operates on the file level and therefore the parity is out of question. Test Storage Spaces on the mirror or simple layouts and you will get better results than in case of Drive Extender.

Storage Spaces is too complex a technology for practical use without special training. A typical computer reviewer who is not tech-savvy in RAID technology spends a week on average (like between this and that posts) to realize that it is impossible to continue writing data to a RAID 5 array of three disks once the smallest member disk is full. For those who know how RAID is organized the reason should be immediately evident - there is no disk space to write parity any longer.

It doesn't make sense to combine several mirrored virtual disks created in Storage Spaces to a RAID0 using Disk Management, Dynamic Disks, and LDM as described here , at least when dealing with not too many disks. Apparently, too many is more than eight disks. If you have eight disks or less, the Storage Spaces driver allocates data in such a way that you get a RAID10 consisting of four disk pairs maximum. It is pointless to impose one more RAID layout on top of this configuration; doing so you can even make the matter worse due to alignment issues. Talking about alignment, it should be noted that stripe on a Storage Spaces virtual disk is 256 KB in size and starts from the beginning of the virtual disk.

It is known that filesystems that you will probably use on Storage Spaces, namely NTFS and ReFS, support TRIM . We have no information about FAT but it is unlikely that someone will use FAT in conjunction with Storage Spaces. So, if you delete a file on a volume located on a virtual Storage Spaces disk, the filesystem driver sends a TRIM command to the Storage Spaces driver. The latter uses the same mechanism as TRIM uses in order to free slabs , i.e. to return slabs that are marked as unused by the filesystem to the pool of free slabs. Returning slabs to the pool of free slabs will take place if: a file being deleted fully occupies one or several slabs; a file being deleted is a single file in the slab meaning that after its deletion this slab would contain no data at all. Once a slab is withdrawn back to the pool of free slabs, it is impossible to easily identify the slab - what volume it belonged to, what location it had in the volume. Therefore, regular data recovery...

If when creating a Storage Spaces volume you used a "thin provisioning" feature, then sooner or later you face the situation when physical space for your virtual hard drive is over. Then, if you need to write data, the Storage Spaces driver can no longer allocate a new slab; it just disables the virtual drive, i.e. makes the drive offline, interrupting the last write operation. To resolve this problem you need to add disk space to the pool. However, it is not always possible, for example in case of four-disk array you would have to bring four disks at once. So if for some reason you cannot add disks immediately but you need to get access to the data, you can go to Windows Disk Management, make the disk online again, then delete unnecessary files and folders. For a while this should be enough but you will have to add disks eventually. However, this doesn't always work. It may happen that whenever Windows Disk Management brings the disk online, the Storage Spaces dri...

People note that write speed on mirror or parity volumes in Storage Spaces is slower as compared to a traditional RAID1 or RAID5. Indeed, parity and mirror volumes of Storage Spaces are not identical to a regular RAID1 or RAID5 in terms of maintenance costs. The ReFS driver that manages the filesystem structure on the Storage Spaces volumes must also calculate checksums over data to avoid the write hole issue.

They say that when Storage Spaces is officially released and when it wins user's confidence the prices of NASes like Drobo, QNAP, or ReadyNAS will drop. We suppose that it is quite possible because a bunch of external USB 3.0 disks connected to a USB 3.0 hub and winded together using a sticky tape may become a cheap and effective alternative. Let's compare these two options based on the NewEgg prices $528 QNAP TS-419PII-US or $535 NETGEAR ReadyNas Ultra 4-bay against the set of $25 Rosewill RHB-610 (RIUH-11001) 4-Port USB 3.0 hub $164 4x SAT3510BU3 3.5" USB 3.0 SATA Enclosure w/ Fan $1 Duct Tape for a total of $190 All additional functions that are available in QNAP or other NASes for example torrent downloads or the capability to access the data via a network from multiple computers, Windows 8 can provide as well (though you may need to use free software like uTorrent)

At homeservershow we came across a pcdoc's story telling about Storage Spaces failure . However based on the description we may suppose that in this case Storage Spaces worked properly, a culprit of failure was a HPT 2680 controller. A RAID controller beeps only in two cases: when the controller itself failed or when one of the disks connected to it failed. If a Storage Spaces pool placed on the disks connected to a controller is about to fail, a controller will not know about it.   Since no drivers were installed, it doesn't make sense to expect a detailed diagnostic from the controller. We can assume that disks were not guilty of a failure, since checking did not detect anything and the disks had good SMART characteristics. So the only remaining possibility is that a controller failure occurred. It is impossible to point out the reason of failure without access to the controller itself. Having looked over user's comments on NewEgg we may assume that it was overhe...

Nowadays we are busy developing the tool that will be able to recover data from a deleted Storage Spaces pool. The recovery should be based on only the data stored in the pool, not on a Storage Spaces data base. We have understood already that the tool will demand quite stern system requirements and will be slow since two passes over disks will be needed. Additionally it is required that all the data is read for each pass. The chance to get an absolutely correct recovery solution is not very good, at least on this stage of design and testing. It is not ruled out that about ten percent of data will be lost irreversibly. We plan to produce the first preview version of the tool in the end of this   year (2012).  The web site for the project is here .

Based on this MS blog post , once you lost a storage space configuration, it is just lost. At the moment, there is a significant difficulty recovering JBODs automatically. What the Storage Spaces subsystem does is, in effect, creation of JBODs of 256MB blocks. So in the end you can have just a plain JBOD, RAID 1 over JBODs, or RAID 5 over JBOD configuration. The capability to put 256MB blocks back into the pool and then use them again as needed, probably for another volume, leads to fragmentation on the pool level. That is, the volume itself gets fragmented, and obvously alignment gets out of window. This means no RAID recovery on Storage Spaces unless some significant breakthroughs are made. Even simple volumes will not be recoverable if they got fragmented.