Jump to content

2TB 7200 RPM vs. Green Drives - Real Differences?


GBH2

Recommended Posts

Hi! I am getting ready to start a server build using unRaid.

 

I have read a lot and continue to do research, but I have a few questions.

 

I understand the two viewpoints regarding 7200 vs. 5400 - faster performance vs. lower power consumption and heat.  (I also understand that a 7200 RPM drive reads/writes from/to a 5400 RPM drive at the speed of the slower drive.) However, I can't seem to really find much quantifiable real world data as to the magnitude of the performance gain and additional power consumed.

 

1. Are we talking about 10% Faster and 100% higher power consumption; or

25% Faster and 25% higher power consumption; or somewhere in between?

 

Basicly, I am trying to decide between the Hitachi 2TB 7200 Drive, and since the Samsung 2TB f4 has been ruled out for now trying to find the 2TB F3 5400 or going to the WD 2TB Green EADS or EARS. I already have a Samsung F2 Ecogreen I can add to the Array(after I offload data)

 

2. If I have a mix of drives 7200 and 5400 is it possible to "fill up" the 5400 drives with data that I will not be accessing often or specify which drives will have which data written to them so that I am doing most of my current Read/Write operations on a 7200 RPM drive? e.g. WMC saving recordings to Disc X, which is a 7200 rpm drive.

 

Thanks!

 

 

Link to comment

Hi! I am getting ready to start a server build using unRaid.

 

I have read a lot and continue to do research, but I have a few questions.

 

I understand the two viewpoints regarding 7200 vs. 5400 - faster performance vs. lower power consumption and heat.  (I also understand that a 7200 RPM drive reads/writes from/to a 5400 RPM drive at the speed of the slower drive.)

Not entirely true.

 

Reads from drives always occur at the native speed of the drive.  So do writes....  The confusion is when part of a protected array.  Then a "write" to the server results in a read, and then write of the SAME sector on a disk.  both occur at the full speed of the disk HOWEVER the disk must rotate its platters a full revolution to get the same sector under the read/write head to write it.  The time to rotate the platter is directly dependent on the speed of the disk.  A 5400 RPM drive rotates about 1/3 slower than a 7200 RPM drive.

 

A write to the unRAID server involves two disks.  The data disk and the parity disk.  The "read" operations are performed in parallel, so are the "write" operations to the two disks.  The slower of the disks involved will therefore dictate the total time needed.  The next set of sectors read/written is not performed until the prior completes.  With that in mind, if either the parity disk OR the data disk is a 5400 RPM drive, the fasted the combined read/write operation can occur is at the speed of the slower rotating drive.  (And it does not matter if it is the party disk or the data disk, or both that are the 5400 RPM disk)

 

If you are writing to two different data drives at the same time, then it will make a difference if you use a 7200 RPM parity drive since it might be better able to keep up with the parallel operations of multiple data drives.    Again, this is ONLY if you are writing to multiple disks at the SAME TIME.

However, I can't seem to really find much quantifiable real world data as to the magnitude of the performance gain and additional power consumed.

 

1. Are we talking about 10% Faster and 100% higher power consumption; or

25% Faster and 25% higher power consumption; or somewhere in between?

From what I've read the power consumption when spinning up is estimated about 1/3 more for a 7200 RPM drive vs a 5400 RPM drive.  Once spinning the difference is not as much.  The 5400 RPM drives tend to take longer to spin up as well. (They use a smaller motor as one of the ways they save energy)

 

As far as the "read" speed, either will be about the same in the server.  The MAX read speed even when not in an array is between 80 and 100 MB/s.  The is easily handled by either type of drive.

 

The effective "write" speed to a 5400 RPM drive is 1/3 less than possible to a 7200 RPM drive (remember, the operation is read, rotate platter, write the sector just read, rotate platter to position for next sequential read, then read next sector, rotate platter, write that same sector, .... again and again.

Basicly, I am trying to decide between the Hitachi 2TB 7200 Drive, and since the Samsung 2TB f4 has been ruled out for now trying to find the 2TB F3 5400 or going to the WD 2TB Green EADS or EARS. I already have a Samsung F2 Ecogreen I can add to the Array(after I offload data)

Entirely up to you.  It is complicated by the fact that unRAID spins down drives.  The difference in power used when sleeping is probably small and could even be higher in a green drive than a non-green.  (depends on how well it goes to sleep with the remainder of its electronics)

2. If I have a mix of drives 7200 and 5400 is it possible to "fill up" the 5400 drives with data that I will not be accessing often or specify which drives will have which data written to them so that I am doing most of my current Read/Write operations on a 7200 RPM drive? e.g. WMC saving recordings to Disc X, which is a 7200 rpm drive.

Yes, you can specify where writes occur.  Either write to user-shares and use the include/exclude rules to include specific disks, OR, write to the disk shares and you'll know exactly where the files are being written.  They can still be read from the user-share view.

 

Again to get the max "write" speed both the data disk and the parity disk must be a 7200 RPM drive. (writes actually being read/rotate-platter/write operations)

 

Having only a 7200 RPM parity drive will have no effect if you are only writing to a single data drive at a time.  It has no effect when reading drives at all. 

 

Joe L.

Link to comment

That's not entirely correct.  Green drives have lower power usage at all power states, not just when spun up.

 

WD Green:

 

Current Requirements

Power Dissipation

Read/Write 6.00 Watts

Idle 3.70 Watts

Standby 0.80 Watts

Sleep 0.80 Watts

 

 

WD Black:

Current Requirements

Power Dissipation

Read/Write 10.70 Watts

Idle 8.20 Watts

Standby 1.30 Watts

Sleep 1.30 Watts

 

There is much more to green drives than the motor and rotational speed.  All of the electronics are redesigned to use less power, and you see those savings even when spun down.

 

Rotational latency is practically nonexistent in normal usage, as the large buffers, write-back caching, and full-track buffering algorithms minimize any practical effect. 

 

Link to comment

My take on the matter is that your drive usage patterns are the most important factor in this decision.  How do you expect to be using your server?  Many people use them primarily as a media archive - meaning that they write their media to the server once, then read it once in a while while playing it back.  In this scenario, most of your drives will be spun down most of the time.  Either speed of drive would work fine, but the 5400's would save you a bit of power long term.

 

However, some people read and write to their server a lot.  Say you are using it to store all the data for your small business, and that data is updated several times per day.  In this scenario, 5400 rpm drives will save you a lot more power since they will be spun up most of the time.

 

Now say you are using your server to in some application where performance is critical (video editing, for example).  In this case you would probably be better off using all 7200 rpm drives and just paying the extra power costs.

 

Personally, my server is used primarily to seed torrents and to serve media to my HTPC.  This means that about half of my drives are spun up at any given time (because my files being seeded are spread out all across the array).  In my case, 5400 rpm drives make a big difference - I value lower power/heat over performance because that's what makes sense for my usage pattern.

Link to comment

Wow! Thank You all for your input and great information. You have given me a lot to think about. :)

 

 

My take on the matter is that your drive usage patterns are the most important factor in this decision.  How do you expect to be using your server? ...

I am going to start with a small 6 HDD server (2TB parity + approx. 9TB Data). I plan on multiple uses:

 

Some data will be business data backup - critical,  but it is very small amounts of data that will only be updated on a weekly basis or when I get around to it. Backup files for several websites and databases. Again nothing that is that big or would be written to or read from often.

 

Some data will be stored media files which are rarely accessed (a lot would probably get deleted if I don't build a multi-Terabyte server. :) I have 400 DVD's I might rip some to disc.

 

(This is where I think speed might be helpful)

I will be downloading large media files(300MB to 1GB), TV Shows and Movies, from the internet. I also will be recording OTA programming through Windows Media Center on my HTPC and I would like to store the files on the server. It is common for me to be recording 2 shows simultaneously while I am watching another show streamed from storage.

 

(I would also appreciate any advice on the best way to accomplish these DVR tasks .) I presently have a HDHomerun Dual Network tuner connected to my HTPC through LAN. I record shows and they are stored on an external 1.5TB drive through eSata(It is filing up fast - that's why I am here :) ).  Is it possible/preferable/advisable/stupid? to do the recording at the server while controlling it at my HTPC?

 

I am now leaning more towards the green drives as it is looking like, as I feared, we are really looking at MUCH higher power consumption for little gain.  Although, I am not ruling out a "mix" of drives quite yet - possibly the Hitachi 7k2000 for parity and "most written to" drive and green for everything else.

 

Your input/opinions on my specific situation would be greatly appreciated.

 

Thanks Again!

Link to comment

I've got a mix of 7200, 5400, and 5900 RPM 2tb drives.  I saw very little practical performance difference between them when loading data to the array.  One big thing I did notice was power consumption.  My initial build had an older 7200 RPM 1.5tb drive and an older 5400 RPM 1tb drive while I was waiting for Microcenter to get more Samsung F3s in stock.  I noticed a significant drop in power consumption as I replaced each of those older drives with Samsung F3s.  Roughly in the neighborhood of 4 watts per drive under load.  (Yes, even the old green 1tb drive was drawing more power than my new 2tb Samsung F3.)  I went from 86.5 watts during parity check to 78.5 watts on a 6-drive array by replacing those two drives.  Idle consumption (drives spun down) stayed pretty steady.

 

IMHO, unRAID isn't really about speed.  It's more about having a crap-ton of data available for immediate access at moderate speed.  Media server, backup target for a few workstations, data archive, etc.  Saving 4 watts/drive across the entire array can really add up.  Especially if you have an array where many of the drives are running constantly.  An extra 1-2mB/s of data transfer won't really stand out.

 

Also, as someone else pointed out, the temperature difference can be significant as well.  My 7200 RPM drives run about 3-5C warmer than my 5900 and 5400 RPM drives during parity check.  I use a 7200 RPM for parity and another for my backup target and misc-storage drive.  Small files like music and photos.  Things that are likely to be accessed in groups.  Everything else is just big collections of mostly HD video and disk images.

 

Comparing minimal performance gains and significant power costs, I ruled out adding any more 7200 RPM drives in the future.  In fact, I'd be happy to see the return of 3600 RPM.  :)  Especially now that we're getting drives with 667gb platters.  The high data density would make up much of the difference.

Link to comment

I will be downloading large media files(300MB to 1GB), TV Shows and Movies, from the internet. I also will be recording OTA programming through Windows Media Center on my HTPC and I would like to store the files on the server. It is common for me to be recording 2 shows simultaneously while I am watching another show streamed from storage.

 

Unless you have OC-48 internet connection for P2P otherwise, no need to worry about it.

if you only have 2 shows at same time, then no need to worry about.

 

Link to comment

When talking about a drive's sequential read performance, we're really talking about how quickly data is moving past the drive's read heads.  There are two ways to increase that rate, one is to have the disk spin faster, and the other is to pack the data more tightly (higher aerial density).  A drive with a higher aerial density can approach or even outperform a faster rotating disk with a lower aerial density.  (The reason that WD 1T "green" 5400RPM EACS/EADS faired well against Seagate's 7200RPM 1T offerings of the day was they offered higher aerial density). 

 

Sequential read performance is an important performance issue for parity checks.  You can have slower spinning drives with higher aerial denisity and get high parity check speeds.  But keep in mind that parity performance is gated by the slowest disk in the array. 

 

For normal disk reads over Samba, sequential read performance of any modern drive is faster than gigabit network performance.  Therefore improved sequential read performance means little to a Samba share user.

 

Sequential write performance on a standalone disk is largely governed by the same factors as sequential read performance.  However, in the case of writes to an unRAID array, sequential write performance is very different.  For each write, unRAID reads a block from both the data disk and the parity disk.  It then calculates the new parity data, and then writes data to both the data and parity disks.  In essence you read a block, and then wait for the disk to make a rotation before being able to do the writes.  No amount of aerial density increase is going to improve that rotational lag.  The slower rotating of the two disks becomes the limiting factor.

 

Sequential write performance is completely irrelevant to parity checks.  No writing is done.  However, for the typical SAMBA user trying to write to the array, or for an in-server process trying to write to the array, sequential write performance is VERY important.  The speed of unRAID for writes is NOT faster than gigabit ethernet.  So improvements in write speed go right to the bottom line (as it were) in terms of improving  end user performance.  If we got to the point that unRAID could do its magic and maintain write performance equal or better than gigabit speeds, then unRAID could be as fast as any network share and further improvements in write performance would be wasted for a Samba user.  But today, even a 7200 RPM drive is not fast enough for unRAID's performance penalty to be overcome.

 

The cache drive can improve apparent write performance, but since it is unprotected space, you take a small risk in using one.  Many users (me included) do not use a cache disk since write performance is reasonably fast in today's unRAID (esp. compared to the abysmal write performance when the cache disk was first introduced).  And each unRAID tweak that improves write performance further narrows the gap.

 

You really need to consider how you will use your array and what performance really matters to you.  Improving parity check speeds requires careful thought and consideration of every disk in the array.

 

Improving write performance requires a fast parity disk and a fast data disk.  In that scenario, writes to that data disk will be as fast as possible without regard to the other disks in the array.

 

I personally have many full disks in my array that are largely static.  Improved write performance to them would be a waste.  And as stated above, normal read access is more than fast enough.  I prefer green drives for this purpose to save power, wear and tear, and reduce heat.  Since my drives all have relatively high aerial density, my parity check speeds are fast enough to easily complete in an overnight cycle.  That's fast enough for me.  About 75% of my data disks fall in this cateogry.

 

But I also have several disks that I write to regularly (e.g, backup disks, digital photos, music, etc.).  For these disks, the extra performance tweak I get from the 7200 RPM drives is noticable, since I do not use a cache disk. For these I prefer the 7200RPM drives to max out my write performance.  (And this requires a 7200RPM parity disk and 7200 RPM data disks).  For me, it is worth the slight increase in power utilization and extra cooling to run them.

Link to comment

But I also have several disks that I write to regularly (e.g, backup disks, digital photos, music, etc.).  For these disks, the extra performance tweak I get from the 7200 RPM drives is noticable, since I do not use a cache disk. For these I prefer the 7200RPM drives to max out my write performance.  (And this requires a 7200RPM parity disk and 7200 RPM data disks).  For me, it is worth the slight increase in power utilization and extra cooling to run them.

 

I am also one who doesn't use cache drive because IMHO once my data write to a RAID, i would to be assured data is protected instead of half-baked.

 

If unRAID would like to keep this cache drive concept, it is better allow user to assign a disk in unRAID protection domain as cache disk, such that user can assign faster disk in RAID domain and data will be moved to other slower disks when system is not busy.

Link to comment

But then it would just be a data disk. If it has parity protection, then it will be slowed down by the parity writing process. You can't have it both ways. If you wish, you can have a data disk that serves this function. Just use your fastest disk, and also make sure your parity disk is the same spec.

Link to comment

GBH2: Thanks for laying out your proposed server usage patterns, that helps us immensely.

 

While reading your post, I had an idea, see what you think:

 

How about an array of all green 5400 rpm drives as data disks and likewise a green drive for parity.  Then add a fast 30 or 60 GB SSD as a cache drive, say for example the OCZ Vertex 2 that is currently on sale.  Here's my reasoning: the green drives are fast enough for nearly everything you want to do.  For your critical business backups, you can set that share to not use the cache drive so that they are written directly into the parity-protected array (alternatively, you could write them to a disk share to accomplish the same thing).  For your DVR application where speed is more important, you can enable the cache drive for that share.  This means that your TV shows will be recorded directly to the SSD cache drive at very fast speeds (though they will be unprotected if the SSD were to die).  They will then later be moved over to the parity protected array on a schedule (you can set the 'mover' script which moves the files from the cache drive into the array to run every hour, every 4 hours, every 8 hours, or however often you like - it won't move a file that is currently in use, so it will ignore any TV shows that are actively being recorded and only move the ones that are complete).  Assuming each TV show is 5 GB or less, a 30 GB SSD would let you record 6 shows before it fills up, and a 60 GB SSD would let you record 12 shows before it fills up.  The SSD will be more than capable of recording multiple shows at once.  If the SSD is full and your DVR wants to record a new show, not to worry - the show will just be written directly into the parity protected array at a slower speed.  I don't think this would actually cause any problems, but you may want to test it just to be sure.

 

Granted, a larger 7200 rpm drive as a cache drive should work just as well as an SSD and give you much larger capacity.  However, the SSD will give you the low power and low heat benefits of a green drive while still matching or even outperforming the performance of a 7200 rpm drive.  Obviously the capacity is greatly reduced, but since the TV shows will be automatically moved off the SSD on a regular basis, that shouldn't matter too much.  The other huge benefit of a SSD is that there's no lag while the drive spins up (since SSDs don't spin).  Normally this lag is only a second or two, which is noticeable but not a huge deal to a user.  However, some programs (such as your DVR app) will freak out if it can't find the data or directory they need immediately.  For example, my XBMC-based HTPC will throw up a network error if my unRAID server doesn't respond quickly enough (which is pretty much every time if the disks are spun down).  An SSD is always available instantly, so the HTPC/DVR doesn't have to wait for anything, it is just ready to go.

 

Also, there's always the option of building your server with all green drives now and just trying it out.  If you have some performance issues, then you can always add a 7200 rpm drive or a SSD at a later point.

Link to comment

But then it would just be a data disk. If it has parity protection, then it will be slowed down by the parity writing process.

 

That is the cost you have to pay for protection. then again it comes back to a question that

 

"if you constantly need fast write speed because there are data generated fast enough, do you trust your data in a single non-protected disk?"

 

If i really need write speed and want to take this "cache disk" approach (FWIW, this is more like a buffering concept in storage subsystem), i will rather use HW RAID1 as cache disk then write my own script/tool to move data to unRAID domain later.

 

Meanwhile, if we don't have time sensitive program that need faster write speed, IMHO, with 7200rpm disks, current write speed in unRAID is already fast enough. Unfortunately hard disk like WD Raptor doesn't have 2TB version.

 

Link to comment

How about an array of all green 5400 rpm drives as data disks and likewise a green drive for parity.  Then add a fast 30 or 60 GB SSD as a cache drive,

 

Similar to flashdisk technology, SSDs have limited numbers of times they can be written to.  That makes them particularly poor choice for the cache drives.  Also, most regular drives are fast enough to keep up with gigabit ethernet speeds, so the performance advantage of SSD would be wasted.

 

I have long advocated for unRAID to allow a software RAID-1 pair to be a part of the configuration.  It could run as a cache disk, if desired, and address the data exposure of using a single cache disk.  Or it could be used to store data requiring higher performance, like a database or VM images.

Link to comment

I have long advocated for unRAID to allow a software RAID-1 pair to be a part of the configuration.  It could run as a cache disk, if desired, and address the data exposure of using a single cache disk.  Or it could be used to store data requiring higher performance, like a database or VM images.

 

In corporation,

database for service such as OLTP that need faster response time, usually will run on top of RAID1.

database for service like data mining that is not that demanding response time and most of time it is read more than write operations usually will run on top of RAID5.

 

Regardless, both have protection because that is the bottom line, you can not sacrifice protection for speed.

 

Link to comment
Regardless, both have protection because that is the bottom line, you can not sacrifice protection for speed.

 

All flavors of RAID have positives and negatives.  RAID5 is fast, but has negatives such as lack of flexibility, poor disaster recovery, and higher power usage.

 

Many people may cringe, but most home users are never going to back-up their unRAID box.  Based on my experience, home servers like unRAID are largely used for 1) commercial media files, that if lost, will have to be reacquired (either re-ripped, or re-obtained by other methods); 2) backups of personal files from their desktop(s); and 3) storage of personal files that are larger then their desktop(s) can hold.  Power users are a vast -- and talented ;) -- minority.

 

#2 is perfectly acceptable by most data standards.

#1 is also acceptable, given the trade-off that the time and resources needed to reacquire the data is acceptable to you.

#3 is playing with fire.

 

In this situation, fault tolerance (1-drive failure) and disaster survivability (2 drive failure) are more important than performance, given that performance is "acceptable."

 

You can have higher survivability for more $$$.  You can have higher performance for more $$$.  You can have both for lots more $$$.  Is it worth the more $$$ for most people?  Nope.  Typical home users don't need a fiber channel SAN.

 

If you apply the unRAID-as-an-appliance paradigm, the green-vs-7200 drive thing is just noise.  Spend more time thinking about what you do for disaster recovery.... spend the $$$ for a full backup offsite, or keep the $$$ and accept that you might have to recreate it from scratch.

 

 

Link to comment

....Comparing minimal performance gains and significant power costs, I ruled out adding any more 7200 RPM drives in the future.  In fact, I'd be happy to see the return of 3600 RPM.  Smiley  Especially now that we're getting drives with 667gb platters.  The high data density would make up much of the difference.

 

Thank you for relating your experiences with using different speed hard drives -  good to know!

 

...

 

 

Excellent information. You've also brought up a lot of things that I have been thinking. I agree that green drives make perfect sense for my rarely accesed files. And, as with many things in life, everything else is a tradeoff! Cache drive - less protection, 1 less array drive/ faster writes - more heat and power. Thank you for your input!

 

GBH2: Thanks for laying out your proposed server usage patterns, that helps us immensely.

Happy to explain it for you. Sometimes when learning new things it is hard to know to ask "the right questions" to get the answers we are looking for. :)

 

While reading your post, I had an idea, see what you think:

 

How about an array of all green 5400 rpm drives as data disks and likewise a green drive for parity.  Then add a fast 30 or 60 GB SSD as a cache drive, say for example the OCZ Vertex 2 that is currently on sale.

Here's my reasoning: the green drives are fast enough for nearly everything you want to do.  For your critical business backups, you can set that share to not use the cache drive so that they are written directly into the parity-protected array (alternatively, you could write them to a disk share to accomplish the same thing).  For your DVR application where speed is more important, you can enable the cache drive for that share.  This means that your TV shows will be recorded directly to the SSD cache drive at very fast speeds (though they will be unprotected if the SSD were to die).  They will then later be moved over to the parity protected array on a schedule (you can set the 'mover' script which moves the files from the cache drive into the array to run every hour, every 4 hours, every 8 hours, or however often you like - it won't move a file that is currently in use, so it will ignore any TV shows that are actively being recorded and only move the ones that are complete).  Assuming each TV show is 5 GB or less, a 30 GB SSD would let you record 6 shows before it fills up, and a 60 GB SSD would let you record 12 shows before it fills up.  The SSD will be more than capable of recording multiple shows at once.  If the SSD is full and your DVR wants to record a new show, not to worry - the show will just be written directly into the parity protected array at a slower speed.  I don't think this would actually cause any problems, but you may want to test it just to be sure.

 

That sounds like a great idea! I had overlooked the idea of a fast cache because I didn't want to worry about losing any "important" data - I was unaware that you could simply bypass cache for any data you desired to. It sounds like it would dramatically increase my "perceived" performance - hey, didn't someone say once "perception is everything"? For my DVR usage the risks associated with a cache drive are unimportant - I wouldn't lose any sleep if I lost a couple of tv shows. :)

 

Granted, a larger 7200 rpm drive as a cache drive should work just as well as an SSD and give you much larger capacity.  However, the SSD will give you the low power and low heat benefits of a green drive while still matching or even outperforming the performance of a 7200 rpm drive.  Obviously the capacity is greatly reduced, but since the TV shows will be automatically moved off the SSD on a regular basis, that shouldn't matter too much.  The other huge benefit of a SSD is that there's no lag while the drive spins up (since SSDs don't spin).  Normally this lag is only a second or two, which is noticeable but not a huge deal to a user.  However, some programs (such as your DVR app) will freak out if it can't find the data or directory they need immediately.  For example, my XBMC-based HTPC will throw up a network error if my unRAID server doesn't respond quickly enough (which is pretty much every time if the disks are spun down).  An SSD is always available instantly, so the HTPC/DVR doesn't have to wait for anything, it is just ready to go.

 

I do love the SSD idea, but I will have to weigh the "limited number of writes" limitation, size and cost versus a 10,000 rpm or good 7200rpm drive for cache.  I absolutely am leaning towards the SSD though for speed, heat and power issues. I'll look into it some more - even if I could only get 2 years out of an SSD, it would be worth it to me.

 

The lag you describe is precisely the reason I posted this topic and am trying to make this decision at a very early stage of my build. While my external green drive has spun up fine for Win 7 MC recordings, I have had "stutters" in recordings that I attribute to doing too many things at once. (and I do have 4GB RAM) I have also had, on several occasions, attempted to download files and before my green drive could spin up got a failure and "No such folder found" message.

 

Also, there's always the option of building your server with all green drives now and just trying it out.  If you have some performance issues, then you can always add a 7200 rpm drive or a SSD at a later point.

Yes, I actually plan on starting out slow and pacing my purchases to put this together. However, I want to have a general game plan in mind as I make decisions about other hardware purchases.  I have actually already gone from planning to "re-purpose" an old P4 ATX pc as a server to deciding to build a 20 disc Norco 4220 setup to finally coming back down to reality and deciding to build a mini-itx 6 disc server(along the lines of your "mini-box" setup that I saw posted). It will be the perfect compliment to my mini-itx HTPC (45 Watt draw at idle) that I built and love.

 

Thanks again for all you help! I am sure I will have many other questions. :)

 

Link to comment

How about an array of all green 5400 rpm drives as data disks and likewise a green drive for parity.  Then add a fast 30 or 60 GB SSD as a cache drive,

 

Similar to flashdisk technology, SSDs have limited numbers of times they can be written to.  That makes them particularly poor choice for the cache drives.  Also, most regular drives are fast enough to keep up with gigabit ethernet speeds, so the performance advantage of SSD would be wasted.

 

I have long advocated for unRAID to allow a software RAID-1 pair to be a part of the configuration.  It could run as a cache disk, if desired, and address the data exposure of using a single cache disk.  Or it could be used to store data requiring higher performance, like a database or VM images.

Excellent point. I am aware of the write limitations , but I think an SSD might still be viable in my situation.

 

A software RAID-1 pair implemented in unraid for cache would be great!

Link to comment

I agree that even if an SSD only lasted a few years it would still be worth it for all the other benefits.  Is there a way to calculate how long it will last?  Might be good to know when to expect to replace it.  Also, by the time it does reach the write limit, I'm sure a replacement unit will be available for $50 or less.

Link to comment

A good rule of thumb for the more expensive SLC (one-bit per cell) based SSD is 100,000 write cycles per cell on average.  Assuming you dump data from the cache drive once a day, that's a long time.  A cheaper MLC (two bits per cell) based SSD has about 1/10th the endurance (10,000 write cycles).  Add in the tricks drive manufacturers play like remapping bad cells, and the lifetime is typically extended even further for either MLC or SLC based SSD's.  I also agree with Raj, even if you do start to see the drive fail, the rate at which NAND technology has been progressing suggests that in 2 years you'll easily be able to find a replacement with more capacity and better performance for less money.

Link to comment

Archived

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

×
×
  • Create New...