Jump to content

Is this a normal write speed? (SOLVED)


Recommended Posts

Under unRAID, my Toshiba DT01ACA300 drives (1 parity, 2 data) get ~67 MB/s write speed, which is half to two-thirds of the 100-115 MB/s I get with Ubuntu Server + Samba, and about one-third of the 180-200 MB/s that these drives are capable of reaching as internal drives.

Link to comment

67MB/s is a VERY good write speed for your array ... 35-45MB/s is much more typical.

 

Remember that every write to the protected array requires 4 disk operations ... 2 reads, 2 writes ... so that parity is maintained (thus providing fault-tolerance).

 

If you create an array without parity; or if you use a cache drive; then you'll get writes in the 100-115MB/s range (maxing your Gb connection speed) ... but the array won't be fault-tolerant.

 

Link to comment

Are you using the reconstruct-write mode ?

 

That would explain the high write speeds.  The only disadvantage I can see to that mode is that all drives have to be spinning, whereas the "normal" mode only requires the drive being written to and the parity drive to be spinning.

 

Link to comment

67MB/s is a VERY good write speed for your array ... 35-45MB/s is much more typical.

 

Remember that every write to the protected array requires 4 disk operations ... 2 reads, 2 writes ... so that parity is maintained (thus providing fault-tolerance).

 

If you create an array without parity; or if you use a cache drive; then you'll get writes in the 100-115MB/s range (maxing your Gb connection speed) ... but the array won't be fault-tolerant.

 

As I have nothing to lose at this point (all data is testing/dummy data), this would be interesting to try just for the sake of knowing. Would stopping the array, unassigning the parity drive, and starting the array up again be sufficient to remove parity protection from the array? Or would I have to rebuild the array from scratch?

 

Are you using the reconstruct-write mode ?

 

That would explain the high write speeds.  The only disadvantage I can see to that mode is that all drives have to be spinning, whereas the "normal" mode only requires the drive being written to and the parity drive to be spinning.

 

Is this the default? I don't recall seeing any setting controlling this, though I might have missed it ;)

Link to comment

As I have nothing to lose at this point (all data is testing/dummy data), this would be interesting to try just for the sake of knowing. Would stopping the array, unassigning the parity drive, and starting the array up again be sufficient to remove parity protection from the array? Or would I have to rebuild the array from scratch?

 

Yes, that would be suficient to remove parity.  I do believe you have to stop and start the array twice though.  After the first time I believe it will show a missing disk (parity) and the second time it will no longer show missing disk.

 

Is this the default? I don't recall seeing any setting controlling this, though I might have missed it ;)

 

It is not the default and there is no GUI setting for it.  Currently it has to be enabled via cli.

Link to comment

I actually tested writing some files lately and I was seeing speeds reaching close to 60MBps so your speed is good.

 

Just an FYI, you should never have to rebuild an unRAID array from scratch just because you want to change the drives around. You could change data disk assignments, break the array into multiple arrays or even take the data disks from 2 arrays and combine them into one and you would never have to start from scratch and re-load the data onto the data disks. After you do any of that, you'd have to allow parity to build but you don't have to start over with your data.

 

Link to comment

As I have nothing to lose at this point (all data is testing/dummy data), this would be interesting to try just for the sake of knowing. Would stopping the array, unassigning the parity drive, and starting the array up again be sufficient to remove parity protection from the array? Or would I have to rebuild the array from scratch?

 

No, if you stop the array and unassign the parity disk, it's going to insist there's a missing parity disk.    What you should do is a "New Config" from the Utils menu ... just assign your data disks with no parity.    This won't cause any loss of data ... but the array configuration will now not have a parity disk.

 

Link to comment

Is this the default? I don't recall seeing any setting controlling this, though I might have missed it ;)

 

I don't believe so.  Tom had at one time talked about making this automatic if all drives were spinning; but I don't think that's how it's implemented at this point.  I think you have to type "mdcmd set md_write_method 1" at the command line to change the write method.

 

The evolution of this option is discussed here:  http://lime-technology.com/forum/index.php?topic=30345.0

 

 

Link to comment

Very true Gary, if you want to remove the parity forever. But if the intent is to put it back after testing then it doesn't really matter that the red-ball and missing parity drive indicators exist during the testing. And it saves having to re-assign all the data drives.

 

For a large array that might be a factor ... but with UnRAID Basic and only two data drives I don't see any reason not to just have a "clean" config with no parity  :)

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...