Yousty

Been using my new setup for a month now and so far the board has been great! Hooked up all 8 hard drives to the mobo ports and unraid recognized all of them on the first boot no problem. As for the processor, it's had no problem whatsoever keeping up with 3 concurrent high bitrate 1080p transcodes at once, the stock cpu fan revs up pretty high during that but no heat issues. Also, I'm only using 1 stick of 4GB DDR3 ram and i've never seen it go above 60% utilization in unraid so apparently ram capacity doesn't matter much with plex.

For anyone curious, I ended up going with the ASRock 990FX Extreme9 Mobo ($130 after rebate) and the AMD FX-8350 CPU ($149) which Passmark shows as having an average of 9,000 score so hopefully that should be good enough for two 1080p streams.

I already have a SATA controller but figured it would be nice to have a MOBO that can handle my current array and then use the SATA controller for future expansion. How important is RAM to Plex? I keep seeing everyone stress the importance of the CPU but I wasn't sure how much the amount of RAM affects it. Also, I'm open to Intel CPU/MOBO suggestions if people feel they would be better.

Some of my media is full BD rips (remuxes) and it would be nice to be able to support at least 2 1080p streams at a time.

I recently installed Plex onto my unraid server for several of my friends to access but I noticed that it's having trouble keeping up with transcoding on some of my higher bitrate 1080p files. My hardware is kind of old (ASRock FM2A85X Extreme4-M, AMD A4-5300, 4GB DDR3 1600) and was built without Plex in mind at the time so I'm looking to upgrade a bit to the best bang for the buck with Plex transcoding as the main focus. My only requirements are I would like to have at least 8 SATA ports (my array is 7 hard drives and 1 ssd cache) and to be around $300. Thanks in advance for any suggestions! Edit: In my preliminary research I was leaning toward the AMD FX-8320 Eight-Core since it seems to have one of the best bang for the bucks when it comes to Passmark score.

Sorry, I guess I wasn't entirely clear in my previous question. There are 3 big steps to a preclear: 1) Pre-read 2) Zero 3) Post-read. For the first cycle it went through all 3 steps and took ~19 hours per step. However on the 2nd cycle it completely skipped the pre-read step and went straight to the zeroing step. Is that normal behavior when running multiple cycles? (I don't know because I've never run more than 1 preclear cycle at a time)

I'm currently running a 3 cycle faster preclear on a Seagate 8TB drive using this plugin, and it's in the middle of the 2nd cycle but I noticed that it skipped the pre-read step and went straight to zeroing the disk as step 1, is this normal? I didn't tick the skip pre-read option box in the plugin and it ran pre-read for the 1st cycle. ================================================================== 1.15b = unRAID server Pre-Clear disk /dev/sdi = cycle 2 of 3, partition start on sector 1 = = Step 1 of 10 - Copying zeros to first 2048k bytes DONE = Step 2 of 10 - Copying zeros to remainder of disk to clear it = **** This will take a while... you can follow progress below: = = = = = = = = Disk Temperature: 32C, Elapsed Time: 63:39:26 1838795+7 records in 1838795+7 records out 3856240254976 bytes (3.9 TB) copied, 23631 s, 163 MB/s Wrote 3,856,240,254,976 bytes out of 8,001,563,222,016 bytes (48% Done)

I'm currently running this process but it doesn't seem to be removing the source files off of disk1 after they're transferred to disk6. Is that something it does as each file is copied or does it wait until all the files have transferred and then do a compare before deleting all the files in succession? Edit: Nevermind, it's deleting the files off disk1 now, it just seems to be on a ~10 minute delay after the file has been transferred.

I'm currently running a preclear on the 4TB drive I just removed from my parity slot, so take these results with a huge grain of salt. I copied an 11.2GB file directly to the array and it took exactly 5 minutes to complete with the speed hovering right around 37MB/s during the entire transfer according to Windows. Which according to my math (11.2GB / 5 minutes = 37.33 MB/s) is accurate. There were no slowdowns or speed ups during the transfer, just a consistent 36-38MB/s. I'll rerun the test again once my preclear finishes in 24 hours to see if it increases any in speed.

To add a little data to the discussion of large parity drives, I just finished replacing my parity drive with the 8TB Seagate shingled drive and it took 20.5 hours to complete the parity sync with an array of 1x2TB, 3x3TB, 1x4TB with all the array drives connected directly to the mobo and the parity drive connected through a SATAIII PCI-E controller.

Just for anyone who is curious my parity sync just finished and it took 20.5 hours total. I have to say so far I'm pretty impressed with this drive, especially considering it only cost me $32.50 per TB. I always write to the cache drive and never write directly to the array so the persistent cache will never be an issue for me.

Here you go: Disk: /dev/sdi smartctl 6.2 2013-07-26 r3841 [x86_64-linux-3.18.5-unRAID] (local build) Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Device Model: ST8000AS0002 Serial Number: LU WWN Device Id: Firmware Version: AR13 User Capacity: 8,001,563,222,016 bytes [8.00 TB] Sector Sizes: 512 bytes logical, 4096 bytes physical Rotation Rate: 5980 rpm Device is: Not in smartctl database [for details use: -P showall] ATA Version is: ACS-2, ACS-3 T13/2161-D revision 3b SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s) Local Time is: Mon Mar 23 20:05:01 2015 EDT SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x82) Offline data collection activity was completed without error. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: ( 0) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 1) minutes. Extended self-test routine recommended polling time: ( 950) minutes. Conveyance self-test routine recommended polling time: ( 2) minutes. SCT capabilities: (0x30a5) SCT Status supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 116 099 006 Pre-fail Always - 106094592 3 Spin_Up_Time 0x0003 099 099 000 Pre-fail Always - 0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 1 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 073 060 030 Pre-fail Always - 21281058 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 74 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 1 183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0 184 End-to-End_Error 0x0032 100 100 099 Old_age Always - 0 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0 189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 067 062 045 Old_age Always - 33 (Min/Max 24/38) 191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 0 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 2 193 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 3 194 Temperature_Celsius 0x0022 033 040 000 Old_age Always - 33 (0 24 0 0 0) 195 Hardware_ECC_Recovered 0x001a 116 099 000 Old_age Always - 106094592 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 240 Head_Flying_Hours 0x0000 100 253 000 Old_age Offline - 12090332938314 241 Total_LBAs_Written 0x0000 100 253 000 Old_age Offline - 15628053208 242 Total_LBAs_Read 0x0000 100 253 000 Old_age Offline - 47784040788 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 No self-tests have been logged. [To run self-tests, use: smartctl -t] SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay.

Sure, I've never run a smartctl report though. Just give me a quick explanation of how to run one and I'll do it as soon as the parity sync finishes in ~7 hours.

For anyone who is curious for a little more real world data, I just finished doing a preclear on my 8TB drive and a parity sync. As for the people wondering about a disk rebuild using one of these, my array is 1x2TB, 3x3TB, 1x4TB and it took just under 12 hours to rebuild the newly precleared 8TB drive as my parity drive to get to the 4TB mark. Now that it's past the 4TB mark and only writing zeroes it's going at 168MB/s, so it should take less than 20 hours to fully rebuild.

As c3 pointed out, jtown already did a parity sync with one of these 8TB drives as the parity drive: Based on the time stamps it's pretty obvious to see that it probably took less than 2 days to complete the entire sync therefore proving that the drive is skipping the consistent cache and just doing full band rewrites during a rebuild.

Ah, I forgot that jtown had already done a partity sync, sorry about that. So why are we debating rebuild speeds if a parity sync has already been done? Is there a difference between a parity sync and a rebuild of a drive?

I'd agree with this IF (and this is a big IF) UnRAID writes the data during a rebuild in a manner that allows the drive to always recognize that full band writes are being done, so it will skip the use of the persistent cache and the band rewrites that would entail. If that's not the case, the rebuild will be FAR longer than the zeroing time [Writing zeroes sequentially throughout the entire disk clearly bypasses the persistent cache -- that's clear from the timings we've already seen posted here]. Hopefully this will prove to be the case -- I suspect either pkn or jtown will do this experiment one of these days and let us know [Or anyone else who decides to buy a few of these to experiment with.] I've got one of these on order that's supposed to be shipping in the next couple days that I plan on using for my parity drive so once I get it and run a preclear cycle I'll be able to start a rebuild with one of these 8TB drives as the parity. I've got 1x4TB, 3x3TB, and 1x2TB as my data array currently, so that should give us a pretty good idea of how long a data rebuild will take with a varying size of drives array. I'll report my results once I start the rebuild in ~2 weeks.

Thank you both for the replies. I had figured this drive would be fine as a parity used in conjunction with a cache drive based on everything I had read in this thread, but just wanted to make sure. I have a 256GB SSD as my cache drive and I've set up mysql to only use the cache drive so the only time data is ever being written to the array for my unraid server is at 3:30am when the mover script runs. Now that you guys have cleared that up for me, looks like it's time to order one of these bad boys!

So my question is, if somebody is using a cache drive in their unraid server like I am and just have mover run nightly (transferring anywhere between 1GB and 50GB in various file sizes per day), will I see issues with having this 8TB drive as my parity?

ShopBLT is actually taking pre-orders (shows they have several coming in on 3/13) at close to the suggested retail price and their FAQ says they ship outside the US. Have you tried ordering from them? http://www.shopblt.com/item/seagate-8tb-archive-hard-drive-sata/seagat_st8000as0002~bym5507.html

It's been 3 years since setting up my unraid server that I completely forgot about mc! Thank you for reminding me and for helping me with this process. Replaced my cache drive a little bit ago and everything is working perfectly. Thanks!

Yes, just not sure which commands to use since I don't know linux.

I'm getting ready to replace my current 64GB SSD cache drive with a 256GB SSD cache drive but am wanting to clone it before I do since I have some apps and data installed on it (mysql for kodi). Can anyone suggest the easiest way of accomplishing this? I'm a very novice linux user and have a Windows 7 desktop I can put both drives in if that is easier.

Has anyone gotten one of these Seagate 8TB SMR drives yet? Really curious to find out how long preclear times are taking.