Julie

As someone who has worked in the storage industry for many years, I thought I would take a moment and clarify what a hot spare is. In a hardware raid system with mirroring or parity drives are required to be the same size. I'll use mirroring for the example, but parity just takes more drives and uses space more efficiently. If drive 1 has "1234567" stored in sector 42, then drive 2 has "1234567" stored in sector 42. That is simple mirroring with 2 copies of the data. If drive 1 fails then sector 42 can just be read from drive 2 and operation continues, however redundance/protection has been lost. This is where the hot spare idea comes in. The only way to restore protection/redundance is add another drive. Keeping one online as a spare allows automatic replacement and the data can be immediately duplicated for protection. Of course having 3 drives for evey two needed would be pretty expensive. Even mirroring gets pretty expensive in large storage facilities, hence the need for parity raid. So what really happens is there may be 1 hot spare online for 10 or 20 drives. It is ready to go when needed because the requirement is that duplication be restored asap. With Drivepool a hot spare is totally unnecessary. It would just be wasting a disk that could be part of the pool and helping performance. (Remember reads and writes can be spread across disks.) Why is it unnecessary? The need for a hot spare is to provide a place to duplicate the information. With Drivepool as long as you have more drives than the number of copies of your data (after a drive fails) then there is a place to recreate the copy. Of course this does require enough overall space. Let's use a concrete example. I have 3 drives in my system. All are 1TB drives. I have my entire pool duplicated 2x. If I have 2TB stored then each drive could be 66% full. (I'll touch on capacity and usage in a minute.) If one drive fails then I still need at least 2TB across two drives to meet my duplication goal. I have two 1TB drives so I just recreate the duplicates and everything is safe again. So, any unused storage space can be used to give me the same ability to restore protection that I get with a hot spare for hardware raid. The formula is duplication count < number of drives and data size * duplication count < sum(drive sizes) - size of largest drive This means you are covered. Drive utilization should normally be maintained less than 80%. (I alluded to this above.) The reason is that allocation for writes slows dramatically in most operating systems when the drive becomes more used. It takes more work to find free space and it tends to be in more small blocks spread about the disk. So you will likely alway have enough space available to handle a drive failure if you normally run <80% utilization and you will have faster disk access. Using an extra disk in your pool instead of having a spare also provides a performance benefit. With 2 drives and duplication of 2 then reading data can happen from both drives at the same time. The result is that read speed is 2x drive speed. If I add a third drive, then I can get 3x drive speed for reads, if the read chunk is larger than the chunks used for duplication. (This is how storage spaces works.) With Drivepool, I believe that entire files are duplicated so this benefit isn't as clear. However, in a server situation where there is a high likelyhood of reading multiple files at the same time we can achive a read speed of Nx where N is the number of drives.

This is a best practices question. Is there a resource or performance penalty for using different duplication settings at a folder level? Would it be better to use multiple pools and set the duplication level for the entire pool? (I realize that in some cases multiple pools is not a good options because of the requirement to dedicate the disks to each pool. In my case, all folders except "videos" have a higher duplication level and separation of pools would be acceptable.)