It's time for an upgrade on the system, and I was window shopping at newegg and found this Seagate Hybrid Drive ST4000DX001.

 

Anybody have any thoughts on the potential use of this drive as a parity drive? I would think it would increase initial write speeds (on files smaller than 7-8GB) without impacting anything else.

 

Can't think of drawbacks, so I am asking the forums.....

IS that drive designed for windows ? It seems that is designed to copy most accessed files to ssd. It seems to be cheaper to buy ssd drive and regular hard drive.

... I would think it would increase initial write speeds (on files smaller than 7-8GB) without impacting anything else. ...

I doubt that. Writing to unRAID means writing to two drives: data drive, and parity drive. Writing speed will be limited by the slowest of the two.

It's time for an upgrade on the system, and I was window shopping at newegg and found this Seagate Hybrid Drive ST4000DX001.

 

Anybody have any thoughts on the potential use of this drive as a parity drive? I would think it would increase initial write speeds (on files smaller than 7-8GB) without impacting anything else.

 

Can't think of drawbacks, so I am asking the forums.....

The parity drive doesn't even have a file system, so it doesn't contain any files.

The Hybrid drives create copies of frequently access files on their internal SSD Cache. This WILL NOT help writing at all as it only caches reads.

The Hybrid drives create copies of frequently access files on their internal SSD Cache. This WILL NOT help writing at all as it only caches reads.

Remember, every write to a parity drive is preceeded by a read of the parity drive. Same thing with data drives, every write is preceeded by a read.

Remember that a write to the protected array requires 4 disk I/O's ... 2 on the parity drive; 2 on the data drive that's involved in the write.    So, as already noted, even if you had a 4TB SSD, the overall speed wouldn't be notably improved, as the 2 operations on the data drive would still be at the speed of the rotating platters.

 

A hybrid drive doesn't cache files ... it caches frequently accessed sectors -- which usually equates to files, but not always.    It does, by the way, help with writes as well as reads, since the initial write is to the SSD, and that is then passed through to the rotating platters ... but from the perspective of the "writer" the write is finished very quickly (as long as you're not writing more than the SSD cache can hold).  But again, this isn't relevant when the system has to wait for the other write (to the data drive) before the process is finished.

 

Bottom line:  It won't hurt to use one; but you won't see any benefit from it.

 

The Hybrid drives create copies of frequently access files on their internal SSD Cache. This WILL NOT help writing at all as it only caches reads.

 

Are we sure?  that suggests they "know" the file system, I suspect it's more likely they just copy continuous clusters to the SSD

yes, clusters, blocks, however you say it. but my experience is that the SSD is for read only.

 

think about it like this.

 

you have 8GB SSD Cache and it populates with your most access files (blocks, clusters, etc.). How can it speed up writes if its full of this cached content???

yes, clusters, blocks, however you say it. but my experience is that the SSD is for read only.

 

think about it like this.

 

you have 8GB SSD Cache and it populates with your most access files (blocks, clusters, etc.). How can it speed up writes if its full of this cached content???

 

The cached content is easily "discarded" from the SSD by just changing the pointers ... it has no impact on the stored data.    So when there's a new write, the drive simply "makes space" for the initial write data and passes it through the SSD.    Different hybrids clearly use different algorithms, so just how large a write will be entirely cached this way, but in most cases I've seen MOST writes will be VERY quick if they're not more than a few MB (i.e. most files), so they're clearly written to the SSD first, and then moved to the actual platters.    All transparent to the user, of course.    But as I noted above, if you think about the physical sequence of events for an UnRAID write, this really doesn't help, since (a) there's a read that precedes the write (to access the current parity sector for the data being written); and (b)  the read and write to the data drive is to a spinning platter, so the fact that the write to the parity drive COULD be much faster is slowed down by the wait for the spinner to complete.

 

 

 

I've tried one one as my data drive and I've yet to see the performance benefit. In comparison the hybrid laptop drives provide a marked improvement. Yet as my data drive housing hundreds of thousands of MP3's I have not realized a performance benefit.  I was hoping/expecting that the LBA's for the directories would have been cached as these drives cache LBA's not files.  I can't say that there is any noticeable improvement at this time. (this may change later as the drive is used more and more).

 

Therefore I would not recommended the extra funds in getting one for parity.  Only for your most read data. Even then I have not seen results to prove this yet.

Plus I would expect as a parity drive, the cache would wear pretty quickly. Another strike in the parity role.

 

I can say that using the Hitachi 7200 RPM 4TB NAS drive as parity provides a good boost in parallel performance over a comparably sized 5400 or 5900 drive.

Even the 6TB NAS drive as parity shows a measurable improvement in the parity role. i.e. those drives can clock at 225MB/s on the outer tracks.

This is especially evident on smaller arrays that use turbo writes.

Agree that if you want to improve your parity drive performance you're far better off getting a 7200rpm drive instead of a hybrid.    The simple fact is that the use case for UnRAID's protected array simply doesn't benefit from hybrid drives.    You could, of course, use a 4TB SSD for parity -- but that's more-than-a-bit cost-prohibitive for most of us 

 

Thanks everybody. This was exactly the conversation I was hoping for. Going with a 7200 drive of normal make up, at least until I can get a 4TB SSD ;-)

... at least until I can get a 4TB SSD ;-)

 

You can "get" one very soon [sandisk has a 4TB unit they just announced, which will be shipping shortly ... but the not-yet-announced cost will almost certainly be over $10,000]

 

... whether you can AFFORD one is a very different question  8)

 

It would, of course, be cool to see a complete 24-drive UnRAID using all 4TB SSDs ... but even Bill Gates would probably balk at the cost of setting this up !!

 

With a specific mSATA controller, you can get 4 1TB mSATA units and RAID0 them for 4TB.

Cost would be approx $2200.

 

Frankly, a small array with turbo write pretty much meets the level to saturate an 1GB ethernet. 

I don't see the need for a 4TB SSD parity.

... 

I don't see the need for a 4TB SSD parity.

 

Me either ... unless, of course, all of your data drives are also SSDs 

... Frankly, a small array with turbo write pretty much meets the level to saturate an 1GB ethernet.

 

I'm surprised at this result.  Unless you're referring to a simple 2-disk (one data plus parity) array, where there wouldn't be a need to read any other data disks to compute the parity result.    Otherwise there are still two sets of disk I/Os needed, so it's a bit surprising you've found this can saturate a Gb network (i.e. ~ 120GB/s write speeds).

 

What was your configuration when you tested this?

 

Nevertheless, I agree there's no need for a 4TB parity SSD      Although I don't use a cache drive (primarily so ALL of my writes to UnRAID are immediately fault-tolerant), if I wanted write speeds that could more or less saturate my Gb network, I'd just use a large cache drive that could easily handle everything I might throw at it in a day.  In fact, prior to v5 being released, there was an expectation that a fault-tolerant BTRFS cache pool would be supported, and this was an intriguing option that likely would have caused me to add a couple SSDs as a fault-tolerant cache.  With the dramatically lower cost of SSDs these days, a pair of 256GB SSDs would be a very nice cache.

 

 

... Frankly, a small array with turbo write pretty much meets the level to saturate an 1GB ethernet.

 

I'm surprised at this result.  Unless you're referring to a simple 2-disk (one data plus parity) array, where there wouldn't be a need to read any other data disks to compute the parity result.    Otherwise there are still two sets of disk I/Os needed, so it's a bit surprising you've found this can saturate a Gb network (i.e. ~ 120GB/s write speeds).

 

What was your configuration when you tested this?

 

4 Disk array, Parity, 3 data drives.  Parity was a 4GB 7200 RPM, Data drive I am writing to is a 3TB Seagate 7200 RPM, The other drives were 5400 RPM drives, but they were only being read from.  So it's 1 write, 2 reads, 1 write to parity. If the drives have caching enabled it's possible to achieve the speeds directly on the array. At least from my benchmark.  I moved batches of mp3s from my workstation with SSD to the array bursting at over 110MB/s. It depends on all conditions being right, yet it's feasible.  If there's another process choking reads on the other drives all bets are off.

A bunch of mp3's (i.e. small files) are also much more likely to be written to the same general area of the disk, so I suspect the reads from the other (non-involved) data disks were mostly already cached in the disks' caches ... this makes it much easier to understand how you could get those speeds.

 

I suspect that if you were writing a larger amount of data (i.e. a few DVDs) that the sustainable speed would be much slower ... although still probably quite good.

 

A bunch of mp3 files is harder to deal with because it's not one single allocation.

There's all sorts of file system housework going on.

 

I also ran a massive batch DD write to the drive and achieved 115MB/s.

 

The science is there dude, People rave how fast raid 5 stripped arrays work. In this case it also works.

As I said, once you do other work on the other drives, all bets are off.

 

It depends on the quality of your drives and how full your filesystems are. Where they are coming from (another machine with SSD as the seed).

 

There's allot of factors. My numbers showed me how fast it can be. I'm not making this up. I get 115MB/s. batch bulk large files via DD.

There was a reason I requested Tom put the tunable back into the driver so I could turn it on and off by schedule.

It works well enough for me that I do not need a cache drive.

 

Do a test with your own hardware and see what you get. 

Every system, network and seed of data is going to react differently.

Not challenging your numbers at all ... just curious what the configuration was that allowed you to achieve that.

 

My arrays all use slower drives (primarily WD Reds, although my older array has a bunch of Green series drives), so even with turbo writes I won't come close to Gb speeds (because the seek times are simply too slow ... not the transfer speeds, which are actually faster than most 7200 rpm drives on the 1TB/platter NAS units).

 

As I've already noted, however, I'm not unhappy at all with my array's performance ... it's plenty fast enough for me.    BUT I don't use it as a primary store, which I gather you do.    All of my UnRAID boxes are used simply as NAS's => one for media;  one for various backups and other data;  and one to backup the other two servers.

 

N54L, unRAID 5.0.6 under ESXi using RDMP (pass through does not work on this platform).  one (1) 2ghz cpu allocated, 4GB ram allocated.

I'm sure there's some penalty running under ESX with a few vm's running too.

 

It's imperative that the parity be a fast 1TB platter 7200 RPM drive.

I've tried with 3TB 7200 RPM and 4TB 5900 (Which still performed really well).  HGST 4TB 7200 RPM and now a 6TB 7200 RPM (Which was a little slower) I believe the better the total drive sizes are matched the better the numbers will be.

 

The other machine is a newer HP GEN 8 micro server intel 1220L, unRAID 5.0.6 under ESXi, 1 CPU allocated,  4GB of ram, Drives mapped as RDMP.

Pass through supposedly works, but I could not get it to work. I also run a few vm's off an SSD on this one too.

4TB 7200 HGST parity drive, the other drives are Seagate 3TB's 7200 and seagate 4TB 5900 RPM drives.

 

They both get similar numbers.

 

You've probably seem me say it on the forum many times those Seagate 3TB 7200 RPM drives are fast. 190MB/s on the outer edge.

The newer HGST 6TB's get 225 MB/s on the outer track.

 

 

I'm finally building my 8 drive server, Can't wait to see what the areca does with 2 3TB drives in RAID0 as parity with turbo write.