March 17, 200917 yr I don't think this was mentioned in the 2 parity drive posts... I would like to see the ability to Stripe drives (at least for the Parity, high use, drive). I know this technically reduces the level of protection, but a failure of a parity drive is not really catastrophic (unless you subsequently lose a data drive; but you have that issue/risk regardless of a striped-parity drive setup). What I believe this setup will do is substantially increase the overall write performance of the unRAID system. For most unRAID boxes (unless the hardware is very old) they have more than enough CPU to do this via Software (therefore staying with the home HTPC/Media backup use/costs). The I/O bus could be an issue, but again, not really different than the already existing issue in this area... one needs to separate HDs on channels in the best possible manner for his/her hardware. Thoughts? I assume this would be relatively easy to do as Linux comes with support for this (and if I'm not mistaken its in the 'md' system already used)?
March 17, 200917 yr I don't think this was mentioned in the 2 parity drive posts... I would like to see the ability to Stripe drives (at least for the Parity, high use, drive). I know this technically reduces the level of protection, but a failure of a parity drive is not really catastrophic (unless you subsequently lose a data drive; but you have that issue/risk regardless of a striped-parity drive setup). What I believe this setup will do is substantially increase the overall write performance of the unRAID system. For most unRAID boxes (unless the hardware is very old) they have more than enough CPU to do this via Software (therefore staying with the home HTPC/Media backup use/costs). The I/O bus could be an issue, but again, not really different than the already existing issue in this area... one needs to separate HDs on channels in the best possible manner for his/her hardware. Thoughts? I assume this would be relatively easy to do as Linux comes with support for this (and if I'm not mistaken its in the 'md' system already used)? Personally, I would not like to see this. The whole point of unRAID as a whole. I would not mind seeing a RAID0 for the parity drive but I kinda doubt I would actually use it at the moment. As it stands now I have a 1.5TB drive as my parity and I don't see me upgrade past that size of drive for a while.
March 17, 200917 yr I would be intersted under the following conditions 1. Parity only 2. It actually made a significant increase to parity tasks 3. It was RAID 0 and you could pull out the second drive without having to rebuild the first
March 17, 200917 yr Author I would be intersted under the following conditions 1. Parity only 2. It actually made a significant increase to parity tasks 3. It was RAID 0 and you could pull out the second drive without having to rebuild the first Yes, I would never want to use this for a data drive; and believe, under certain hardware configs, you would get a large performance increase in Writes to the unRAID. As for #3; I doubt you could do that... as it defeats the purpose of striping. From what I understand, ever "block" is split in two, half written to each disk. So if one drive fails, you lose your parity protection. As I originally stated, not a huge deal... replace the failed disk and rebuild the parity (like you would have to do if your single parity drive failed). Is there anyway to test this setup? I would be interested to see what kind of performance increase could be gained... I doubt it would be double, but a 50% gain would be worth considering full implementation.
March 17, 200917 yr I would be intersted under the following conditions 1. Parity only 2. It actually made a significant increase to parity tasks 3. It was RAID 0 and you could pull out the second drive without having to rebuild the first Yes, I would never want to use this for a data drive; and believe, under certain hardware configs, you would get a large performance increase in Writes to the unRAID. As for #3; I doubt you could do that... as it defeats the purpose of striping. From what I understand, ever "block" is split in two, half written to each disk. So if one drive fails, you lose your parity protection. As I originally stated, not a huge deal... replace the failed disk and rebuild the parity (like you would have to do if your single parity drive failed). Is there anyway to test this setup? I would be interested to see what kind of performance increase could be gained... I doubt it would be double, but a 50% gain would be worth considering full implementation. This is correct, with RAID0, each block is written to the next subsequent drive. With my tests I've seen a slight speed increase. With Concatenation, the second (or multiple) drive(s) are appended to each other. This may allow an increase in parallel write if they are on different area's of different disks, yet would be minimal. you could pull out the second drive without having to rebuild the first Even though possible, I question that the programming involved for the MD driver would be worth it.
March 17, 200917 yr Each write requires 4 I/Os ... 1. Read the existing data sector 2. Read the existing parity sector <wait until both reads are done> 3. Write the updated data sector 4. Write the updated parity sector It is hard to see how RAID0 on parity would have any substantial impact on performance on any of these. The best way, IMO, to get better write performance from unRAID is for Tom to have an option to have a RAID-1 cache drive. That would provide redundancy and good performance. There is a thread in the features request thead about this.
March 17, 200917 yr Author Each write requires 4 I/Os ... 1. Read the existing data sector 2. Read the existing parity sector <wait until both reads are done> 3. Write the updated data sector 4. Write the updated parity sector It is hard to see how RAID0 on parity would have any substantial impact on performance on any of these. The best way, IMO, to get better write performance from unRAID is for Tom to have an option to have a RAID-1 cache drive. That would provide redundancy and good performance. There is a thread in the features request thead about this. Wouldn't RAID-1 double those steps (unless you were using hardware to do the mirror)? I'll check out the other thread. As for RAID0, you would theoretically double performance of each of those steps (in my RAID0 setups I use on my workstation, I have seen 60-80% increases in Read performance alone).
March 17, 200917 yr Each write requires 4 I/Os ... 1. Read the existing data sector 2. Read the existing parity sector <wait until both reads are done> 3. Write the updated data sector 4. Write the updated parity sector It is hard to see how RAID0 on parity would have any substantial impact on performance on any of these. The best way, IMO, to get better write performance from unRAID is for Tom to have an option to have a RAID-1 cache drive. That would provide redundancy and good performance. There is a thread in the features request thead about this. Wouldn't RAID-1 double those steps (unless you were using hardware to do the mirror)? I'll check out the other thread. As for RAID0, you would theoretically double performance of each of those steps (in my RAID0 setups I use on my workstation, I have seen 60-80% increases in Read performance alone). From RAID wiki ... "RAID1: Increased read performance occurs when using a multi-threaded operating system that supports split seeks, very small performance reduction when writing." I'm likely over my head here ... but here goes .. RAID0 breaks the disk into "chunks" and stripes the chunks across the disks. If you are reading or writing in large chunks, the advantage is clear. I'm not sure parity works that way. Perhaps the parity process could be coded in a way to make a RAID-0 parity disk perform better. Regardless, if you only have RAID0 on the parity side, the speed on the data drive accesses would act as a governor. In another thread RobJ mentions that the fact that you are reading a sector and then writing it immediately afterwards results in a full disk rotation delay. This is part of the reason that writes to the array are slow. I don't think RAID0 would help. Interestingly - in theory - RAID1 might do a better job, because the read could come one disk and the write go to the other.
March 18, 200917 yr In another thread RobJ mentions that the fact that you are reading a sector and then writing it immediately afterwards results in a full disk rotation delay. This is part of the reason that writes to the array are slow. I don't think RAID0 would help. Interestingly - in theory - RAID1 might do a better job, because the read could come one disk and the write go to the other. RAID1 would require writes to both drives, causing the wait issue anyway. I.E. unless the cache is large enough and write back cache on drive is enabled. The issue should not be reads as usually there are multiple sectors read and cached at the same time. As for RAID0, you would theoretically double performance of each of those steps (in my RAID0 setups I use on my workstation, I have seen 60-80% increases in Read performance alone). Theoretically.. Yet Practically, It may not if the strip width is not large enough. With my tests I've seen a slight speed increase What is slight? I used hardware RAID0 on a SIlicon Image external SATA drive. The performance increase was around 3MB/s. For me it did not pay considering the cost of hardware, cost of electricty to run the two drives 100% of the time because they cannot spin down in that particular hardware configuration. I plan to try a caching controller one of these days to see if that helps. Overall the biggest improvement was moving my parity drive to a 1.5TB 32MB Cache 7200 RPM drive even though my other drives were only 1tb.
March 19, 200917 yr Very interesting that you did not see any performance gain on a raid 0 (3MB/s). Have you tried the same thing using a raid zero for your cache drive? I am assuming you were using a silicon 3132 chipset. What if you used an SSD drive for cache? The prices are coming down now. I do not think the price point will be there for a raid 0 of ssd drives for cache, unless you have money to lose. Has anyone tried using a veloraptor drive 15K for either cache or parity in raid 0?
March 19, 200917 yr Very interesting that you did not see any performance gain on a raid 0 (3MB/s). Not really. Raid0 realizes its best results in small, random access environments. It's performance in large, sequential access is not nearly as good. Seek times are what primarily benefits from RAID0.
March 19, 200917 yr Very interesting that you did not see any performance gain on a raid 0 (3MB/s). Have you tried the same thing using a raid zero for your cache drive? I am assuming you were using a silicon 3132 chipset. I saw an improvement, just not one worth the extra expenditure in hardware. It was a SIL3132 to a SiI5744 Steelvine Processor. What if you used an SSD drive for cache? The prices are coming down now. I do not think the price point will be there for a raid 0 of ssd drives for cache, unless you have money to lose. Has anyone tried using a veloraptor drive 15K for either cache or parity in raid 0? I don't think an SSD would buy that much for a cache drive. You are still limited to the network speed. As far as a 10K or 15K drive, the speed of the spindle isn't going to amount for that much on cache because you are still limited to the network speed. On parity it might help. What I read was the Seagate 7200 32MB cache 1.5TB drives are as fast as the smaller Velociprator drives. I'll mention this again, if unRAID supported a caching raid controller or SCSI(and we could compile our own) I'm sure we could realize throughput enhancements.
March 19, 200917 yr All SSDs are not created equal.... http://www.anandtech.com/printarticle.aspx?i=3531 Not to mention the "aging" effects.
Archived
This topic is now archived and is closed to further replies.