Posts

Showing posts from October, 2012

Storage Spaces Recovery system requirements

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. So 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.

Storage Spaces vs. Drive Extender

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.

Too complex for wide acceptance

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.

Combination of Storage Spaces and Dynamic Disk RAIDs

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.

Helium hard drives revisited

In the article about use of helium in hard disks from Xyratex some aggressive change is offered. Helium is absolutely inert - it interacts neither with surface of platters nor other disk components. Thus, if the disk is filled with helium, the protective platter covering can be made thinner or even completely omitted. However, the side effect may arise: if the disk loses hermeticity and helium escapes, surface of platters will be oxidized quite quick and data will be lost. To kill a regular hard disk you need to open it and fill it with dust. For disk without protective covering it is enough to leave it without helium for a month. In this case it is impossible to put the disk aside and try to recover data from it, say, in a year.