ohlwiler

According to Storage Review the 7K4000 uses 22.69 watts during startup and consumes the most power of all of the currently available drives. 22 7K4000 drives would thus need 500 watts if started simultaneously. The 860 will easily do the job. A 650 watt power supply would easily do the job. http://www.storagereview.com/hitachi_deskstar_7k4000_review

That will work fine. It only provides power, cooling and quick access to the drives. As such it is transparent to any OS. That said, it supports SAS drives and SATA drives.

Thanks Joe for giving my idea some thought, how about this: data1 data2 parity Address 0 11111111 00000000 11111111 Address 1 11111111 00000000 11111111 Address 250G 11111111 00000000 11111111 <- we zero this Address 500G-1 11111111 00000000 11111111 <- to here Address 500G 11111111 10000000 01111111 Address 500G+1 11111111 00000000 11111111 Address 750G 11111111 00000000 11111111 Can’t we store the “real data” at the end of the new drive? Is it an issue with the pointers to the data by the filesystem?

To calculate my speedup in parity I first logged a parity calculation by capturing the current time and the position of the parity calculation every 30 seconds. After staring at this graph and seeing my parity calculation times jump up when my 1T WD green drives were finished it dawned on me that removing them from consideration for the first half of parity calculation would really speed things up. The parity calculation graphs (calculation speed vs. position) for the first half and second half of the calcuation were about the same. I estimated my first half speeds based on the lowest speed 2T disk (100 MB/sec WD green). The read rate for the first 1T of my parity calculation and second T were roughly equal, so I used my actual time for the second half of my parity calculation. Overall I estimated a reduction of about 20%. I could get more accurate numbers if I did a recalculation of parity without my slow drives in the mix, but I don't have an extra 2T drive around. In thinking about it I believe that my situation is about the worst case, so that is why I stated up to 20%. Replacing a smaller drive with a larger drive would be trivial. Instead of zeroing the end of the drive, we would zero the start.

The calculation of parity is performed by all drives being written to at once. At position one each bit is read from each drive. An Exclusive-OR operation is performed on these bits and a value is calculated. This value is written to the parity drive. The speed of these calculations is constrained by the speed at which the data can be obtained from the individual data drives. This speed is determined by the speed of the drives themselves or the data bus to which they are attached. Most unRAID systems being built today place the hard disks on a PCIe bus to prevent the data bus slowing the parity calculation, therefore the speed of the drives themselves becomes the limiting factor. Most systems utilize a mixture of disk sizes. These smaller drives have lower areal density and thus lower data read rates. During parity calculation these small drives slow down parity calculation until they are read from completely. Because the data read rate is a function of the areal density, the read rate at the inner tracks of a hard disk is much lower than those at the outside. This degradation is about a factor of two on the disks we tend to use in unRAID. We can reduce and sometimes eliminate the reduction in parity calculation speed by shifting the smaller drives until the end of the parity calculation. To do this would of course require a change to the way the unRAID software. Smaller drives would have an offset added to their first address such that the last bit on all drives would occur at the same time, unlike now where the first bit is aligned. In my calculations this would speed up my parity calculations by twenty percent. I have a mixture of 1T. and 2T. drives, some 7200 and some 5400-5900. In no case would this ever decrease performance of the parity calculation. If all drives are of equal size, then parity would of course be the same as it is now. This would require a software change on Tom’s part. The major downsize is that the parity disk would be different between two different versions of the software. Downgrading UnRAID release versions would not be possible without a parity recalculation. A couple of things could be done to help alleviate the transition. Write out the parity creating method on the parity disk itself; warn the user if this signature is not recognized. Allow users to opt in to this parity creation method, so they will only invoke it once they know the risks. I for one would jump at the chance to decrease parity check times. I just spent several hundred dollars upgrading because my parity calculation times were getting out of hand. Now I want that last little bit. Scott