Seagate releases 8TB 3.5inch drive

[Squid]

I personally plan to use two PMR-type 4TB drives in RAID-0 for parity. This would give me 8 TB "fast" parity drive, and allow using of 8 TB data drives in array. And, at the same time, would allow to avoid slower writing to other, PMR-type data drives, in array (slowing of writing to SMR data drives seems to be unavoidable).

And double your chances for a parity drive failure

[c3]

 

So yes, using an SMR drive for parity would slow down any and all writings to unRAID (read speed should not be affected).

 

So what data do you have that supports this?

[pkn]

I personally plan to use two PMR-type 4TB drives in RAID-0 for parity. This would give me 8 TB "fast" parity drive, and allow using of 8 TB data drives in array. And, at the same time, would allow to avoid slower writing to other, PMR-type data drives, in array (slowing of writing to SMR data drives seems to be unavoidable).

And double your chances for a parity drive failure

I'm prepared to tolerate this.

[WeeboTech]

I personally plan to use two PMR-type 4TB drives in RAID-0 for parity. This would give me 8 TB "fast" parity drive, and allow using of 8 TB data drives in array. And, at the same time, would allow to avoid slower writing to other, PMR-type data drives, in array (slowing of writing to SMR data drives seems to be unavoidable).

And double your chances for a parity drive failure

 

True, the possibility exists, yet in my experience. I never had the RAID0 parity drive fail. It was always a data drive. The parity drives outlasted the data drives by a wide margin.  Use highly reliable drives for the RAID0 array.  Keeping in mind, the performance improvement in RAID0 is a small margin, so the return on investment may not be worth it for many people.

 

Given that SMR drives are going to be slow, I believe the return on investment to provide the ability to exceed a 6TB spindle may be worth it in a confined case.

 

Then there is also the ability to do a multi-RAID configuration (which saved my butt) i.e RAID0/RAID1 SAFE50 Hybrid.

[pkn]

 

So yes, using an SMR drive for parity would slow down any and all writings to unRAID (read speed should not be affected).

 

So what data do you have that supports this?

 

No data, just logic. Writing to unRAID means writing to two drives: data drive and parity drive. Speed of writing will be limited by the slowest of the two.

[c3]

 

So yes, using an SMR drive for parity would slow down any and all writings to unRAID (read speed should not be affected).

 

So what data do you have that supports this?

 

No data, just logic. Writing to unRAID means writing to two drives: data drive and parity drive. Speed of writing will be limited by the slowest of the two.

 

I suspect there are other factors to write performance, otherwise there are a whole bunch of drives limited to 80MB/sec (which few unRAID system write performance exceed).

[WeeboTech]

 

So yes, using an SMR drive for parity would slow down any and all writings to unRAID (read speed should not be affected).

 

So what data do you have that supports this?

 

No data, just logic. Writing to unRAID means writing to two drives: data drive and parity drive. Speed of writing will be limited by the slowest of the two.

 

I suspect there are other factors to write performance, otherwise there are a whole bunch of drives limited to 80MB/sec (which few unRAID system write performance exceed).

 

They probably burst at a high rate, but once you've reached 2x memory in transfer data, I would believe it to slow down to at least 50% of the slowest drive or less. Perhaps 30-40% or so.

[garycase]

... They probably burst at a high rate, but once you've reached 2x memory in transfer data, I would believe it to slow down to at least 50% of the slowest drive or less. Perhaps 30-40% or so.

 

That sounds about right.  The initial reads of the two drives are clearly delayed by the seek times; and then after the reads the writes have to wait for a full drive rotation (~ 11ms for 5400rpm drives) ... so there's a lot of "waiting time" involved relative to the actual transfer times.    Burst rates are clearly much higher, since the data is buffered at that point.

 

But for any significant amount of data, the burst rates are irrelevant, since once the buffers are filled performance is limited by the physical capabilities of the drives -- this is where the "SMR penalty" is likely to have a notable impact.  But until we see the actual performance in an array just how bad this will be is simply conjecture.    Clearly Seagate has made some adjustments to the drive's firmware to help mitigate this, but when a band needs to be rewritten there's not much you can do except rewrite it -- which can take a "long" time relative to non-SMR drives.

 

[Helmonder]

 

So yes, using an SMR drive for parity would slow down any and all writings to unRAID (read speed should not be affected).

 

So what data do you have that supports this?

 

No data, just logic. Writing to unRAID means writing to two drives: data drive and parity drive. Speed of writing will be limited by the slowest of the two.

 

Well.. no...

 

write speed is dependent on the " writing speed" of the unraid system itself AND on the writing speed of the two drives..

 

The overhead of the unraid system makes for a very slow writing proces anyway, so disk speed might not make a real-world difference ?

[pkn]

...

The overhead of the unraid system makes for a very slow writing proces anyway, so disk speed might not make a real-world difference ?

Valid consideration, but, being a developer of seismic data processing applications (read: a lot of IO and even more numbercrunching), I can not, in this case, imagine "overhead" (RAM/CPU etc.) activities which would be slower than HDD access.

[garycase]

... so disk speed might not make a real-world difference ?

 

NO!!  The disk speed is effectively the ONLY thing that matters.  The primary "overhead" that results in the slow write speeds is simply the 4 disk I/O's that happen do do a single write [2 reads and 2 writes].    Computational overhead is irrelevant ... it's so much faster than the disk that it effectively takes no time at all.

 

UnRAID does provide a way to eliminate the impact of this overhead [or, more correctly, to defer the impact to a time when the user won't notice it] ==> the use of a cache drive.    With a cache drive, the array writes are deferred to a time when the system is hopefully not otherwise being used (i.e. the "Mover" runs and does the actual array writes).    The downside is that the data isn't fault-tolerant until it's moved to the array [unless the cache is a btrfs RAID-1 pool, which can be done with v6]

 

[WeeboTech]

 

So yes, using an SMR drive for parity would slow down any and all writings to unRAID (read speed should not be affected).

 

So what data do you have that supports this?

 

No data, just logic. Writing to unRAID means writing to two drives: data drive and parity drive. Speed of writing will be limited by the slowest of the two.

 

Well.. no...

 

write speed is dependent on the " writing speed" of the unraid system itself AND on the writing speed of the two drives..

 

The overhead of the unraid system makes for a very slow writing proces anyway, so disk speed might not make a real-world difference ?

 

The real issue is the 4 IO's using the same devices.

 

Depending on the width of your array (mine are 4 wide) Turbo write makes a measurable difference for long running writes as long as there is no other reads/writes going on.

 

It makes such a difference in my usage pattern that I have a cron to turn it on and off by my schedule of usage.

I don't worry about the other drives spinning all day.

I just rsync them to a backup server every now and then and do what I have to do.

 

In this case, the RAID0 parity would surely provide a benefit especially if an advanced caching controller were used.

 

When I used the areca x1 controller for a RAID0 set, Parity sync vs parity check were very different.

I.E. Parity sync was measurably faster due to the path of reads/writes.

A fast RAID0 parity set 'can' provide a measurable difference depending on how the system designed with I/O paths.

[Helmonder]

... so disk speed might not make a real-world difference ?

 

NO!!  The disk speed is effectively the ONLY thing that matters.  The primary "overhead" that results in the slow write speeds is simply the 4 disk I/O's that happen do do a single write [2 reads and 2 writes].    Computational overhead is irrelevant ... it's so much faster than the disk that it effectively takes no time at all.

 

UnRAID does provide a way to eliminate the impact of this overhead [or, more correctly, to defer the impact to a time when the user won't notice it] ==> the use of a cache drive.    With a cache drive, the array writes are deferred to a time when the system is hopefully not otherwise being used (i.e. the "Mover" runs and does the actual array writes).    The downside is that the data isn't fault-tolerant until it's moved to the array [unless the cache is a btrfs RAID-1 pool, which can be done with v6]

 

Gary,

 

I am sure you are right but I do not get it... Unraid's write performance is EXTREMELY slow when using parity compared to writing to a disk without unraid... In my head this can only mean that UNRAID (and not the disk) is the main party in write speed..

 

Now if THAT is the case, then I should not be worried in using a disk for parity that is slow.. Since for the major part disk speed is not the part that takes up the most time..

 

Again... sure you are right, but can you make me help understand ?

[garycase]

When you write to a disk without UnRAID, the data is written to the sector where it goes ... period.  So the only overhead is seeking to the appropriate track, waiting for the correct sector to rotate into position (latency), and then writing the data.

 

When you write to a protected array in UnRAID, the data can't simply be written to the sector where it needs to go.  First, UnRAID has to READ the sector where it's going to write the data [with the same overhead I just noted -- seek and latency delays];  then it has to READ the corresponding sector on the parity disk [another set of seek and latency delays] => these reads are so UnRAID can keep parity in sync [it has to know what data WAS on the sector so it can compute what changes it needs to make to the current parity; and it has to read the corresponding parity sector so it knows what it's changing].    Now UnRAID has to write the data to the data disk and write the updated parity sector to the parity disk [These writes will normally only involve latency delays, since the heads will already be at the correct cylinder due to the seeks for the reads].

 

Note that the only computational overhead added by UnRAID is calculating the updated parity values => and it has an entire disk rotation to do this without actually adding any time to the process [one rotation at 5400rpm ~ 11ms; at 7200rpm it's ~ 8ms -- either is PLENTY of time to complete those computations].

 

So it's not UnRAID that's causing the slow writes -- it's simply the process of updating parity ... and the time to do that is entirely dependent on just how fast the disks are.    Note that if set up an UnRAID array WITHOUT parity, the writes will be MUCH faster ... since every write will just require one disk I/O -- to simply write the data to the disk.  No extra operations required ... but then you also would not have a fault-tolerant system.

 

The other ways to mitigate the write speed are (1) Use a cache drive -- writes are directly to the cache drive, with no extra disk I/O during that write (the slower writes to the array are done later when the mover runs);  or (2) use Turbo-Write, which, instead of doing 2 reads and 2 writes, does  (N-1) reads (where N = the number of data disks) and 2 writes.  If all disks are spinning, this will generally be faster, since it doesn't have to wait for 2 rotations of the data and parity disks -- it simply reads all of the OTHER disks, writes the data to the data disk, and then computes and writes the parity value to the parity disk [No need to read the previous data value or parity value because it simply computes the new parity value from all of the disks].    In other words, instead of 2 disk operations to each of 2 disks; there is 1 disk operation to every disk. (thus saving the time for an extra disk rotation)

 

 

[trurl]

When you write to a disk without UnRAID, the data is written to the sector where it goes ... period.  So the only overhead is seeking to the appropriate track, waiting for the correct sector to rotate into position (latency), and then writing the data.

 

When you write to a protected array in UnRAID, the data can't simply be written to the sector where it needs to go.  First, UnRAID has to READ the sector where it's going to write the data [with the same overhead I just noted -- seek and latency delays];  then it has to READ the corresponding sector on the parity disk [another set of seek and latency delays] => these reads are so UnRAID can keep parity in sync [it has to know what data WAS on the sector so it can compute what changes it needs to make to the current parity; and it has to read the corresponding parity sector so it knows what it's changing].    Now UnRAID has to write the data to the data disk and write the updated parity sector to the parity disk [These writes will normally only involve latency delays, since the heads will already be at the correct cylinder due to the seeks for the reads].

 

Note that the only computational overhead added by UnRAID is calculating the updated parity values => and it has an entire disk rotation to do this without actually adding any time to the process [one rotation at 5400rpm ~ 11ms; at 7200rpm it's ~ 8ms -- either is PLENTY of time to complete those computations].

 

So it's not UnRAID that's causing the slow writes -- it's simply the process of updating parity ... and the time to do that is entirely dependent on just how fast the disks are.    Note that if set up an UnRAID array WITHOUT parity, the writes will be MUCH faster ... since every write will just require one disk I/O -- to simply write the data to the disk.  No extra operations required ... but then you also would not have a fault-tolerant system.

 

The other ways to mitigate the write speed are (1) Use a cache drive -- writes are directly to the cache drive, with no extra disk I/O during that write (the slower writes to the array are done later when the mover runs);  or (2) use Turbo-Write, which, instead of doing 2 reads and 2 writes, does  (N-1) reads (where N = the number of data disks) and 2 writes.  If all disks are spinning, this will generally be faster, since it doesn't have to wait for 2 rotations of the data and parity disks -- it simply reads all of the OTHER disks, writes the data to the data disk, and then computes and writes the parity value to the parity disk [No need to read the previous data value or parity value because it simply computes the new parity value from all of the disks].    In other words, instead of 2 disk operations to each of 2 disks; there is 1 disk operation to every disk. (thus saving the time for an extra disk rotation)

Great write-up. I already understood all this, but thanks for putting it down in such detail. I expect I will be linking to this in the future.

[pras1011]

Anyone using these yet?

[Squid]

Anyone using these yet?

http://lime-technology.com/forum/index.php?topic=36749.msg351930#msg351930

[pras1011]

I meant in a unraid server

[jtown]

Anyone using these yet?

 

 

Edited to add:

 

Crap.  Hit post instead of preview.

 

I just got one a couple-three days ago and did some speed tests on it.  They're in the longer thread in this section that I'm too lazy to link to right now.  Keep in mind, the tests were done with the drive in its USB3 enclosure (because it was $45 cheaper than a bare drive) and I didn't want to shell it until it passed diagnostics.  It passed so I'm going to pop it out of the case tonight and play around with it some more connected directly to a SATA/600 controller.

 

FWIW, it did pretty darn well.  I did all the tests on a small, ~12 gig partition with the intention of restricting the activity to a small physical area so that it would have to re-write over the same area.  Sequential read/write was 177/119 MB/s.  Random 512k read/write was 49.5/89.0 MB/s.  10 gig file group writes took 1:35-1:45 with large files, 20-30 minutes when I used a set with hundreds of thousands of files.  10 gig file group reads took 1:00-1:05.  The big mess o' files read test was all over the place so I assume there was a problem with my methodology.

 

After I pop it out of the case, I'll do the tests again and see if it's any faster.

[pkn]

OK... few more bits and pieces.

 

The 8TB Seagate seems to have capacity of:

8,001,563,222,016 bytes.

 

My 4TB HGSTs, pair of which I plan to RAID-0 to obtain 8TB parity drive have 4,000,787,030,016 bytes each, two will be:

8,001,574,060,032

 

So, parity will be a tad bigger than 8TB data drive, so there is a hope that this might actually work. Now, I'll have to wait patiently until the drives arrive and pass preclear.... a week, not less. Oh my.

 

[WeeboTech]

OK... few more bits and pieces.

 

The 8TB Seagate seems to have capacity of:

8,001,563,222,016 bytes.

 

My 4TB HGSTs, pair of which I plan to RAID-0 to obtain 8TB parity drive have 4,000,787,030,016 bytes each, two will be:

8,001,574,060,032

 

So, parity will be a tad bigger than 8TB data drive, so there is a hope that this might actually work. Now, I'll have to wait patiently until the drives arrive and pass preclear.... a week, not less. Oh my.

 

 

SWEET!!! I can't wait to see the outcome of this.

What controller are you using to do the RAID0?

[garycase]

... So, parity will be a tad bigger than 8TB data drive, so there is a hope that this might actually work.

 

Clearly that will work fine -- good thing the size works out (I just confirmed that this is universally true -- at least for the drives I checked (1TB, 1.5TB, 2TB, 3TB, 4TB, and 6TB in addition to this 8TB) => i.e. 2 x any drive has more bytes than the single drive of the same size.  I suspect that's not at all coincidental 

[Helmonder]

When you write to a disk without UnRAID, the data is written to the sector where it goes ... period.  So the only overhead is seeking to the appropriate track, waiting for the correct sector to rotate into position (latency), and then writing the data.

 

When you write to a protected array in UnRAID, the data can't simply be written to the sector where it needs to go.  First, UnRAID has to READ the sector where it's going to write the data [with the same overhead I just noted -- seek and latency delays];  then it has to READ the corresponding sector on the parity disk [another set of seek and latency delays] => these reads are so UnRAID can keep parity in sync [it has to know what data WAS on the sector so it can compute what changes it needs to make to the current parity; and it has to read the corresponding parity sector so it knows what it's changing].    Now UnRAID has to write the data to the data disk and write the updated parity sector to the parity disk [These writes will normally only involve latency delays, since the heads will already be at the correct cylinder due to the seeks for the reads].

 

Note that the only computational overhead added by UnRAID is calculating the updated parity values => and it has an entire disk rotation to do this without actually adding any time to the process [one rotation at 5400rpm ~ 11ms; at 7200rpm it's ~ 8ms -- either is PLENTY of time to complete those computations].

 

So it's not UnRAID that's causing the slow writes -- it's simply the process of updating parity ... and the time to do that is entirely dependent on just how fast the disks are.    Note that if set up an UnRAID array WITHOUT parity, the writes will be MUCH faster ... since every write will just require one disk I/O -- to simply write the data to the disk.  No extra operations required ... but then you also would not have a fault-tolerant system.

 

The other ways to mitigate the write speed are (1) Use a cache drive -- writes are directly to the cache drive, with no extra disk I/O during that write (the slower writes to the array are done later when the mover runs);  or (2) use Turbo-Write, which, instead of doing 2 reads and 2 writes, does  (N-1) reads (where N = the number of data disks) and 2 writes.  If all disks are spinning, this will generally be faster, since it doesn't have to wait for 2 rotations of the data and parity disks -- it simply reads all of the OTHER disks, writes the data to the data disk, and then computes and writes the parity value to the parity disk [No need to read the previous data value or parity value because it simply computes the new parity value from all of the disks].    In other words, instead of 2 disk operations to each of 2 disks; there is 1 disk operation to every disk. (thus saving the time for an extra disk rotation)

 

Right... Think I got it... So the parity process is indeed what is making things take longer (this is obvious, I knew that), however this is not so much the actual processing, but the fact that writes and reads have to be done several times making the process last longer (this is what I did not get).. Therefor a speedy disk will make a difference..

 

That means that the 8TB Seagate will be a bad idea for a parity disk... Will need to wait for something quicker.. I will not go the raid0 route, I am one of the guys that would appreciate a 2nd parity disk, going the raid0 route for the parity disk will make sure I have 0,5 of a parity disk instead of 1 ;-)  The wrong way around..

[pras1011]

Instead of everyone guessing how it will be as a parity drive maybe someone should actually try it out?

 

Maybe it will be different!!

[BRiT]

Instead of everyone guessing how it will be as a parity drive maybe someone should actually try it out?

 

It's not guessing. It's educated speculating.