so one of my HDs stopped powering up (this is a test array, so zero data loss).

 

I am replacing it [5400rpm] with a 7200rpm drive.

 

it is a different manufacturer [toshiba] than the other drives in either of my arrays [mostly WD, 1 samsung].

 

is there any benefit of setting the 7200 as parity? OR should i put the most frequently used data on it?

 

or just plug in and let data entropy determine what gets it...

What do you do with your server? Write once read many? (media server) Write and erase constantly? (office file server)

 

Parity drive speed helps with writes, erases, and changes, data drives determine read speeds. (it's not quite that simple, but close.)

 

Jonathan

well - hybrid is probably the best answer... I have a share for Videos, which are WORM; and I have a share that I store my virtual machine vmdk's on.

 

I was thinking of sticking the vmdks on the 7200 to see if the VMs are more responsive. but then again, feel a faster parity drive will increase the perceived performance system-wide. OR is the slower spindle of one going to slow down the other, and negate any performance increase the new drive could have bought?

Writes involve both the data drive and the parity drive, so increasing both will stand the best chance of optimizing things. However, since writing to multiple data drives will be held up by the parity needing to be updated for both locations, so a faster seek time will be best served by the parity drive if you only upgrade one. VM files are read and write heavy, so if it were me, I'd put the fastest drive I could as parity, then take advantage of unraids ability to use multiple size drives to put an SSD as my VM storage. That way reads should be extremely fast, and writes as fast as $$ will allow.

 

Alternatively, host your VM's on a fast unprotected volume, and do periodic backups.

thanks!

 

that's kinda what I was leaning towards.

 

and yes, the esxi host has an SSD on it, unprotected with only 1 VM booting off it... that gets backed up nightly. I was thinking of moving the boot drive of the other major vm onto the SSD as well.

 

I will need to read up on SSD + Unraid - I thought there were unresolved issues with that. If I go that route, will the slow parity still hold me up? Again, if the machine boots quickly (which i'm assuming is mostly read) then that would be my win/win right? SSD to Unraid + 7200 to Parity = best available config.

I would approach this as to the most immediate need first.

 

vm's are read and write heavy.  But I would say most of the time it's going to be reads, so you will want that to be accessible as fast as possible.

 

After that ,

I would suggest upgrading the parity to the fastest parity you can afford.

 

Some will say it doesn't matter, but if you are doing vm's you want a fast drive to read from, then a fast drive for parity.

 

After that I would do what was necessary to put my most used VM's on an SSD and do backups to the fast array drive.

This way if the SSD dies, you can still function from the array.

 

Probably more upgrades then you were thinking about but that's how I would do it.

 

When I upgraded from 5400s to 7200s, I upgraded Parity first, but it was because of torrenting.

 

There were lots of lil writes going on. It did help a great deal, but I was also not sitting behind an interface using a VM.

 

After I upgraded the Data drive to 7200, the machine operated so much better. Even though the rest of the data drives were 5400, the two most used drives at the highest speed made a big difference in how the server performed.

 

Adding memory and doing a sysctl vm.highmem_is_dirtyable = 1 will provide a noticeable change in writes.

It will allow the kernel to use the buffer cache more thus buffering some of the writes into chunks.

Adding memory and doing a sysctl vm.highmem_is_dirtyable = 1 will provide a noticeable change in writes.

It will allow the kernel to use the buffer cache more thus buffering some of the writes into chunks.

 

thanks - some very good points raised in this thread. I am going to put the 7200 at parity then. perhaps add the SSD into the Array. I have a 1TB Samsung f3 - I think it's slightly faster than the WD "Green" drives. so backups can go there.

 

the line about memory has me intrigued. I have 24GB, the absolute max my board will support... I haven't seen that setting... is that something I run inside unraid console? do I need to do it after each reboot?

 

this is getting better with iteration

 

edit: found your thread here: http://lime-technology.com/forum/index.php?topic=25431.0

Adding memory and doing a sysctl vm.highmem_is_dirtyable = 1 will provide a noticeable change in writes.

It will allow the kernel to use the buffer cache more thus buffering some of the writes into chunks.

 

thanks - some very good points raised in this thread. I am going to put the 7200 at parity then. perhaps add the SSD into the Array. I have a 1TB Samsung f3 - I think it's slightly faster than the WD "Green" drives. so backups can go there.

 

the line about memory has me intrigued. I have 24GB, the absolute max my board will support... I haven't seen that setting... is that something I run inside unraid console? do I need to do it after each reboot?

 

this is getting better with iteration

 

edit: found your thread here: http://lime-technology.com/forum/index.php?topic=25431.0

 

 

Those Samsung F3's are fast. in my benchmarks they reach 160MB/s on reads.

The only other drive I saw that was faster is the 3TB seagate 7200RPM.

 

 

So I would upgrade parity and then use the Samsung F3 for my data store or backup drive until I purchased an SSD. 

 

 

Those Samsung F3's are fast. in my benchmarks they reach 160MB/s on reads.

The only other drive I saw that was faster is the 3TB seagate 7200RPM.

 

 

So I would upgrade parity and then use the Samsung F3 for my data store or backup drive until I purchased an SSD.

 

yeah - I had x2 of those F3s - been quiet and fast- one just refuses to power on anymore... I have an SSD, 256GB... it isn't part of the array ATM. however, once I sort everything out (and put my Pro key to use) I will add it as part of the Array... I didn't realize that it was a valid option.

 

 

hmm... brainstorm as I am typing this... my HTPC has a WD black! I got it to record live TV ... which I don't really do much of anymore. The black ought to out perform the F3, no?

I can just swap before I put data on the F3...

[ The black ought to out perform the F3, no?

I can just swap before I put data on the F3...

 

I wouldn't know for certain without testing it.

 

You could mount it in the unRAID machine without adding it to the array.

 

Then do a

dd if=/dev/sd? of=/dev/null bs=4096 count=1024000 to see what the max read speed of the outer tracks on the drive will be.

 

Substitute the ? with the actual drive letter.

 

By reading the device directly, you will be bypassing all filesystem specifics, so you do not have to mount the drive.  Do this for both drives.

 

This will be what the drives raw max speed could possibly be.  Actual read off a filesystem will be a lil slower, but it will give you an idea.

 

There are many other things that come into play such as filesystem type, journaling and firmware routines.

 

If you have a reiserfs on the F3, you could try my writeread10gb script to see how fast it handles things with the other layers of performance. 

 

In reality, you would not be moving 10GB to the drive at a time if it's a data store, so burst speed is what will be important.  You can modify the writeread script to use a smaller size.

 

Another tool I've used is hddtune. Gives me basic benchmarks. Works for me.

I can't find definitive specs on the 1TB F3 ... but I do know that the 1TB WD Black is a two-platter drive;  so whether or not it would outperform the F3 depends on whether the F3 has one or two platters.

 

Give the same RPM, the areal density will determine which drive is fastest -- and 1 single platter drive will have far better density.

 

The best way to confirm it is to simply do as suggested above -- mount the drives, and test their outer cylinder transfer rates.

 

yea - can't hurt to try it while 1 drive is still empty. it's a relatively easy process. after it gets filled with data, then - i'll have an issue.

 

also - as far as controlling what drive to store the VMDKs... right now, I have it under a user share... and I just let fate decide where things will go. if I want control of it. I occasionally go in to the disk share to balance things out (if disk1 is getting full, move stuff to disk2 so that something can finish writing). Can I create a folder via a disk share, and then access it via a user share?

You can include or exclude disks from particular user shares.

 

Considering that speed is the utmost importance for VM's you may want to use a direct disk share rather then the user share.

 

From my understanding, the usershare adds a layer that slows things down 'slightly'.

 

You can include or exclude disks from particular user shares.

 

Considering that speed is the utmost importance for VM's you may want to use a direct disk share rather then the user share.

 

From my understanding, the usershare adds a layer that slows things down 'slightly'.

 

ah duh! forgot about that. This is how it will be. i'm doing a "fresh" install/config of the latest 5.0 build. going to move my data over manually (instead of upgrading)...

 

going to use this moment to re-engineer things.

 

to summarize:

 

1. put the 7200 drive for Parity

2. add the SSD as part of the Array

3. boot drives of the most used VMs go on SSD

4. data drives go on the Samsung F3.

5. sysctl vm.highmem_is_dirtyable=1

6. ?

7. profit

 

missing anything?

so reading around - looks like most folks are using SSD for a cache drive? and that only helps on when the file is getting created, right? a vmdk, which once created will only be modified would see no benefit with a cache drive...if I am understanding correctly.

 

is it generally a bad idea to just add a 256 GB SSD as part of the array? Or am i mixing apples and oranges here?

so reading around - looks like most folks are using SSD for a cache drive? and that only helps on when the file is getting created, right? a vmdk, which once created will only be modified would see no benefit with a cache drive...if I am understanding correctly.

 

is it generally a bad idea to just add a 256 GB SSD as part of the array? Or am i mixing apples and oranges here?

 

 

A .vmdk will be continually updated with lots of random reads/writes.  your virtual machine will benefit greatly with a .vmdk on an SSD.

 

 

I personally wouldn't put the SSD as part of the array, however I would back it up frequently to the array.

If the ssd is part of the array, then writes will be as fast as your slowest drive, being the parity drive.

This may or may not have an impact on your usage.

I basically agree about not adding an SSD to the array, with one caveat:  while it's true that any write to the VMDK will involve both the SSD and your parity drive -- thus slowing the writes to the speed of the parity drive -- it's also true that MOST activity (booting, program loads, etc.) is read-only;  so that would see a big benefit with an SSD.    In addition, a lot of the writes are very small, so would likely be fully cached in UnRAID's memory, thus not slowed down by the cache speed.

 

So an SSD as a member of the array, used solely for VMDK storage, would likely provide both much faster virtual machine access and full fault-tolerance for your virtual machines, with a small write penalty when writes were slowed down by the cache drive.

 

I agree, however, that a better alternative is to use the SSD "outside" of UnRAID -- and to simply have a timed synchronization utility that backs it up to the UnRAID server.    Not as fault-tolerant (obviously "at risk" in between syncs) ... but zero write degradation during VM operation.

 

buy 7200rpm drives. The price difference is minimal compared to the speed boost and general performance you get out of a faster more robust drive.

In addition, a lot of the writes are very small, so would likely be fully cached in UnRAID's memory, thus not slowed down by the cache speed.

 

 

Only if they are small chunks. It also depends on how you tune/retune the kernel.

Fastest burst speed I achieved on writes was about 60MB/s.  For one virtual machine that would be fine. When you start to have a few with some constant random writes it changes things.

There's also a basic tuning that once writes are at a certain level, the writes stop being cached and go directly to the array.

 

 

Given this, you could work on retuning the kernel or just put the SSD out of the array and have very high read/write levels with no drives spinning. Just put into place a good automated backup plan.

Agree -- as I noted above -- that keeping the SSD "outside of the array" with a good automated synchronization utility to keep it backed up is the best approach.    The only downside to that is the VM isn't always fault-tolerant ... but it's only "at risk" for the changes since the last sync.  I tend to agree that if we're talking ONE VM, it may be just fine to keep the SSD in the array and live with the write hits to gain full fault-tolerance;  but if there are multiple VMs involved, I agree with your point about the writes slowing down to normal array-writing speed (typically 30-35MB/s).

 

man - i didn't get the email notifications and you guys filled up a whole page in my absence!

 

okay - so I will keep it outside of the array. My two critical VMs are a win7 and an SBS 2011 machine. Both of which are backed up using the SBS's backup tools. and those backups are shot over the ether to CrashPlan. My win7 boot drive is already on the SSD, outside of the array, and is blazing fast. I've hesitated to put the SBS on the SSD only because I've never been through a full server restore, so I don't know how "good" the backups are. I guess I should test the restore process and get comfortable. Keeping the SSD out of UnRaid also lets me use the Mobo headers and keep the BR10i for full 2TB drives.

 

Thanks everyone - I appreciate the thoughtful insight. To say I've learned a lot in this thread would be an understatement ;-)