June 11, 201214 yr I understand that write speed is slow on UnRaid. I get average of 30MB/sec It would be great to improve write speed by double in the future version (maybe 5.1). Is it possible?
June 11, 201214 yr You would need SSDs for parity drives to speed up write speeds to the array. Just use a cache drive.
June 12, 201214 yr I understand that write speed is slow on UnRaid. I get average of 30MB/sec That is about as good as it gets. The process of writing involves not only the write to the device you are writing to, but also a read from, and write to, the parity drive. Unless hard drive write speeds increase drastically, you're not going to see an improvement. It would be great to improve write speed by double in the future version (maybe 5.1). Is it possible? The only way to get an (apparent) improvement is to install a cache drive. I say 'apparent' because all you are doing is delaying the slow write to the destination device and, until that delayed write occurs, the data you have written is not protected by parity.
June 12, 201214 yr Here my benchmarks so far. 2 WD 1TB Green 5400 in RAID0 for data. 2 WD 1TB Green 5400 in RAID0 for parity. Running dd from /dev/zero to the Areca volumes is about 120MB/sec sustained. Parity check is running now at about 150MB/sec. Writing to disk1 over SMB is around 70MB/sec sustained. It can be done... you need faster drives.
June 12, 201214 yr Here my benchmarks so far. 2 WD 1TB Green 5400 in RAID0 for data. 2 WD 1TB Green 5400 in RAID0 for parity. Running dd from /dev/zero to the Areca volumes is about 120MB/sec sustained. Parity check is running now at about 150MB/sec. Writing to disk1 over SMB is around 70MB/sec sustained. It can be done... you need faster drives. Is there any reason you chose to stripe green drives? This seems like an odd choice, unless you already had the drives ofc. This setup fascinates me and I may consider something similar for a second 'faster' unRAID server down the track.. Seems quite costly losing 50% storage per disk share though. Sent from my iPhone using Tapatalk
June 12, 201214 yr I had the drives, and they are cheaper than black or blue WDs. I don't lose any space... they are in RAID-0, not RAID-5 RAID0 parity has some other benefits... it has some help to writes for other non-RAID0 drives, and if I want to go from 2TB to 3TB, all I have to do is expand the RAID0 array with another spare 1TB drive. I keep only 1 RAID0 data drive, just for the things I want "fast"... the other drives are all conventional unRAID drives, for storage.
June 12, 201214 yr I understand that write speed is slow on UnRaid. I get average of 30MB/sec It would be great to improve write speed by double in the future version (maybe 5.1). Is it possible? Unraid isn't meant for speed. 30MB/sec is most likely what you'll see it top off at. If you want something like 95MB/sec then you'll have to go for a Synology type box. I have one and I get a constant 95MB/sec on write speeds.
June 12, 201214 yr I was thinking about RAID0 for the parity drive. I think it would suit me better than say a parity + cache setup. @bubbaQ When you mention writes to drive 1, is that drive the RAID0 array or a standard drive?
June 12, 201214 yr Using the parity + cache with HITACHI 5K3000 drives I get 60 - 105 Mb/s write, if I take take the cache drive out I get about 40 - 45 Mb/s write speed. I say just get good drives and use the cache drive option to speed things up.
June 12, 201214 yr I don't lose any space... they are in RAID-0, not RAID-5 Sorry, for some reason I was thinking RAID-1 not RAID-0, brainfart. Having a striped parity drive + 1 data makes total sense. Out of curiousity, do you have disk1 as its own share? Do you set your disk1 to spin-down at all?
June 12, 201214 yr I don't lose any space... they are in RAID-0, not RAID-5 Sorry, for some reason I was thinking RAID-1 not RAID-0, brainfart. Having a striped parity drive + 1 data makes total sense. Out of curiousity, do you have disk1 as its own share? Do you set your disk1 to spin-down at all? Yes, it is its own share, and it spins down (per Areca FW, not unRAID).
June 12, 201214 yr Disk1 is RAID0. Parity is RAID0. The other drives are standard. Would it be safe to say that the write speed to standard drives would be similar (i.e. 70MB/sec range) since the bottleneck is the parity drive?
June 13, 201214 yr the bottleneck is the parity drive? The bottleneck is NOT the parity drive. It is the SLOWER of the parity drive and the data drive you are writing to.
June 13, 201214 yr the bottleneck is the parity drive? The bottleneck is NOT the parity drive. It is the SLOWER of the parity drive and the data drive you are writing to. It is the SLOWER ROTATIONAL SPEED of the parity drive and the data drive you are writing to. Each disk involved must make one rotation to read, and then rotate the platter one revolution to write the same sector. Faster spinning disks will be able to read and then write faster. (Both disks being 7200 RPM will result in faster throughput than when either is rotating at 5400 RPM)
June 13, 201214 yr (Both disks being 7200 RPM will result in faster throughput than when either is rotating at 5400 RPM) Not always true. Areal density and throughput, along with the buffering algorithms can provide a 5400 RPM drive that will actually have faster writes in unRAID than a 7200 RPM drive.
June 13, 201214 yr (Both disks being 7200 RPM will result in faster throughput than when either is rotating at 5400 RPM) Not always true. Areal density and throughput, along with the buffering algorithms can provide a 5400 RPM drive that will actually have faster writes in unRAID than a 7200 RPM drive. I am not disagreeing with the logic, but could you share one make and model of a 5400 rpm drive that has the capabilities (proven) over a 7200 rpm drive.
June 14, 201214 yr A WD400BB (Legacy Product), really? Let's try something at the very least to be the same size and interface. Cache and amounts of platters (internals, etc) can be different. Your compare does hold up, not exactly something someone would second guess if going to a WD20EARX would be slower than a WD400BB
June 14, 201214 yr Sure. A WD20EARX (5400rpm) vs a WD400BB (7200rom) I've looked high and low on the interwebs, and I can't find a full spec sheet on the green drive. Are you SURE the seek times and latency are better? I know the transfer rates are better, but that's a result of more data passing by the head per second. I can't wrap my head around the concept of sequential reads and writes of the same sector being faster if the drive only brings that sector under the read heads once per revolution. Does it take more than 1 spin of the platter to get the job done on the older 7200 drive? Or does it take multiple rotations on all drives, and the newer electronics / heads / coils takes fewer rotations? How many licks does it take to get to the center of a tootsie roll pop?
June 14, 201214 yr A drive supporting NCQ would also likely take less rotations for r/w than one which does not.
June 14, 201214 yr Heck, I've got a 32GB MTron SSD that is slower than the WD400BB! And sectors per track can make a big difference. If you have 3 times the SPT, you need 1/3 the revolutions to read/write the same amount of data! Consider this.... we have all seen drives that only have half the throughput on the inner cylinders than the outer cylinders. No consider a 7200 rpm drive that has performance due to the same topography on its outer cylinders of a 5400 rpm drive on its inner cylinders.
June 14, 201214 yr I don't lose any space... they are in RAID-0, not RAID-5 Sorry, for some reason I was thinking RAID-1 not RAID-0, brainfart. Having a striped parity drive + 1 data makes total sense. Out of curiousity, do you have disk1 as its own share? Do you set your disk1 to spin-down at all? Yes, it is its own share, and it spins down (per Areca FW, not unRAID). Which Areca card do you have?
June 14, 201214 yr A drive supporting NCQ would also likely take less rotations for r/w than one which does not. NCQ is disabled by default in the unRAID settings (Force NCQ disabled = Yes).
Archived
This topic is now archived and is closed to further replies.