danioj

No worries. Happy to contribute any way I can. Yep. Agree. I am quietly confident as I tested the hell out of the drives before I deployed them and with the 3 yr warranty they come with coupled with the fact I have a FULL backup now I am not worried. If they fail they fail (all drives will anyway) and i'll RMA. If I get 3 years out of them before a fail and have to retire them Ill consider I have had my moneys worth - BUT I won't queue the Seagate sucks debate again! Read it too much!

That increase in speed around 85% was a bit of a spike just as I took the screenshot. I monitored and it went back down to ~500KB/s straight away. I've just added another screenshot at ~89% to the post above to prove it. Next update in that post will be the last one! And Yes I set it auto verify! Ill let it run. Well, there we go. Small File Test has completed. http://lime-technology.com/forum/index.php?topic=36749.msg373188#msg373188 Basically my observations are that the copy started at ~1MB/s and then "settled" on ~500KB/s. It fluctuated somewhat between 500KB/s and 1MB/s but those were only "bursts". I had verify copy set and while it wasn't as quick as the larger files it was faster than the write. As the post indicates the verify read speed was sustained at ~5.5MB/s. As was noted above I did NOT experience any "Freeze" of any kind - which was predicted could happen as the persistent cache once filled was cleared. I think that whatever Seagate has done to mitigate the SMR technology it has been done excellently and it mitigates any observable write penalty we have been discussing and speculating about. All in all - whether you've got your Unraid Array filled with Large (~5GB to ~40GB), Medium (~400MB to ~4GB) or Small (<=215KB) Files then I have observed and now reasonably expect this drive to behave on Par with the WD Red PMR drives I have in my Main Server. Based on my testing and observations I believe these are Excellent Drives which I would recommend for anyone using Unraid as I (and I believe allot of others in the community) do. That goes for use as an Data or Parity Drive. I will certainly be putting these drives in my Main Server as well as my Backup Server now. And will do so without fear. I think my testing on these drives is done unless someone can put a good enough argument together to do more. c3 had suggested to see the impact of a full persistent cache, disabling the drives write cache with hdparm BUT I don't see the need to do that now. What I wanted to see is if during real world use I would experience any degraded performance from my WD Red PMR drives in normal use in an Unraid environment and I clearly have NOT experienced any of that. Time to delete the crap from my Servers. Happy Days.

That increase in speed around 85% was a bit of a spike just as I took the screenshot. I monitored and it went back down to ~500KB/s straight away. I've just added another screenshot at ~89% to the post above to prove it. Next update in that post will be the last one! And Yes I set it auto verify! Ill let it run.

Thanks. I noticed there was about 2 hours between the first two status posts -- at 0% and 13% ... so extrapolating that rate as long as the drive's don't hit the "full persistent cache" wall I suspect you'll be done with that by about the 15 hour point. I'll look for your subsequent status updates There seemed to be a website problem in the night that was stopping me from posting. Database connection was the error I got. Anyway, updated with all the screens shots I took. Up to ~85% now.

As requested, starting the copy of the small files to the Backup Server now and Ill let it run till completion and will check in with progress! 0% (1.2MB/s after 30 of 390,688 files) 13% (813KB/s after 53,505 of 390,688 files totalling 6.38GB of 46.56GB) 30% (563KB/s after 117,051 of 390,688 files totalling 13.95GB of 46.56GB) 42% (500KB/s after 165,674 of 390,688 files totalling 19.75GB of 46.56GB) 58% (438KB/s after 228,366 of 390,688 files totalling 27.22GB of 46.56GB) 85% (875KB/s after 334,593 of 390,688 files totalling 39.88GB of 46.56GB) 89% (575KB/s after 347,650 of 390,688 files totalling 41.44GB of 46.56GB) 100% (938KB/s after 387,723 of 390,688 files totalling 46.22GB of 46.56GB) Post Write File Verification Read Speed It is "Faster" than the write. Sustained ~5.5MB/s

Ta, I did not know that! It appears I can get good deals on the MX Series and will go with that!!

All, Sorry it has taken me so long to run and post results of the Small Files Test. Work has been crazy and I've been working interstate Anyway, I'm back and I've had some time this weekend to run the test so here goes. P.S. I have deleted the last post where I put this information together and replaced it with a link to this post! I read a few posts before posting this so upped the memory of the VM and also decided to run the tests separately instead of simultaneously and I copied the data to the VM itself rather than via a share on the iMac. So In summary: I am running this within a Windows VM on an Core i5 iMac with the VM having 4GB of Memory allocated and 1 CPU thread using Terracopy to copy files from the VM to a share on my Main Server (without Cache drive and containing 3TB WD Red's) and my Backup Server (without Cache drive and containing the new 8TB Seagate's). I have generated a test data set of ~400,000 files totalling ~50GB of data across 10 folders, each folder containing 10 files of 128KB each and several levels deep! I had the files auto generated randomly as I mentioned earlier and I stopped the generation when I hit ~50GB. I set a testshare up on both the Main Server and the Backup Server. Both shares without the use of a Cache Drive and both using the Most Free Fill Setting. Main Server & Backup Server Main Pages Main Server & Backup Server Share Pages Main Server & Backup Server Share Details TestFiles Preparation TestFiles Details from the VM I did a baseline speed test for copying a file between the VM and there servers (a W7 iso) and as you can see the speed of the transfer was as fast as the other tests I have done. ~40MB/s. Baseline Test Main Server Baseline Test Back up Server I was happy from what I was seeing in the baseline copy that the ability to copy from the VM to the two servers was sound so I started the test. Test Main Server Beginning ~1MB/s Test Main Server .5% After .5% ~500KB/s The variation in speed between those numbers was maintained for another .5 % to 1% complete where I decided to stop. Test Backup Server Beginning ~1MB/s Test Backup Server .5% After .5% ~800KB/s Once again the variation in speed between those numbers was maintained for another .5% to 1% where I decided to stop. It seems based on this test that the performance of copying files of this size is just as poor irrespective of which server I copy to. I didn't really want to let it run as I didn't see the point. Running at this speed is not going to show us anything I don't think. I am not sure what conclusions to draw from this test. I don't feel it has given me any new information on the Seagate's than I had before. The performance of this test to both servers was the same. Shockingly slow. Not sure if anyone wants me to do anything else .....?

Just got back from Working away. Tooooo long!! Thanks for the kind words. Just did an update, be sure to make note of what I have entered in the Memory section of the Main Server. Only issue I have had with planning this build!

Post edited as it was incomplete. Please refer to the following post later in the thread: http://lime-technology.com/forum/index.php?topic=36749.msg373164#msg373164

You're observations match my own. My view is that vendors are inflating the price. My view is that they see the other 6TB drives so close in price and are like - woah - this is an 8TB drive the average consumer won't know the difference in applied technologies (eg SMR over PMR) so we can still charge more! So they do.

Good catch! I'll apply the settings and do as you suggest. I'm travelling again - this time to ADL. Back Wednesday night! When I got this morning the script had generated 32GB of data so still some way off 50GB. So I hit Ctrl-Z and paused the thing. I'll resume it when I get back and start the copy. Better to be there to monitor and take screen shots anyway!! Hope you're enjoying the lake!!

OK - I have started preparing. For everyones benefit here is a screenshot of how I am preparing the test. Basically I am running a script that is generating files of 128KB. 10 Files per folder and 10 subfolders per folder and down 6 levels. I'll cancel the script when it hits 50GB and that will be the test data set.

Lake Travis while sipping a Margarita I am sooo jelous! I could provide the baseline data too! I can execute two copies side by side from my W7 VM on my iMac. One to the Main Server (made up of WD Red 3TB's) and the Backup Server (made of of the Seagates). I have spoke with c3 about some more advanced tests (as I interpret them) BUT I am also interested in just doing a real world test and this seems like it would fit the bill. Ill generate a set of data with files of ~215k and about 50GB of them and ill distribute them randomly over a directory structure about 20 deep. Then I'll run the copy to both servers simultaneously! Should do it I think!

These days, the average filesize given (215k) is considered small. 50GB would 243,854 files. You could stick to the case mentioned, 170,000 files of 215kb each. But the directory structure will have a significant impact. 170 directories of 1,000 files is different that one directory of 170,000 files. In the use case of unRAID, you could leverage split level to gain access to more cache. I could use this: http://dottech.org/116607/windows-review-filetool-program/ Set the file size to 215k and about 50 folders for 500MB and then spend some time doing some copying and pasting down about maybe 20 levels up to 30-50GB?

Just weigh in my friend. This is all for the community so by knowing your scenario we can best get some supportive data and results. I dont "Think" it matters how they were created (sequentially or not) it matters how they are written. Ta, Ill have a look!

I just don't have that many files of the size you mention. I would be happy to test a set of files of the size you want and then post results. Maybe there is a "file generator" I can use. I am SURE there is, just need a good quick one. Ill have a look. I could then create 35GB made up or 170,000 files and test for you. OK - I found one. http://www.7tutorials.com/3-ways-create-random-dummy-files-windows-given-size. Not tested it yet but should be simple enough. Lets try and test this once and for all and find the threshold. We ALL "know" at some point the writes are going to slow down - I think we are all just looking for a real world example of when and under what scenario. So what do people think of 50GB of "small" files? What do we really define as "small"? (The man said to his wife .. )

I just don't have that many files of the size you mention. I would be happy to test a set of files of the size you want and then post results. Maybe there is a "file generator" I can use. I am SURE there is, just need a good quick one. Ill have a look. I could then create 35GB made up or 170,000 files and test for you.

The Silverstone DS380 has 8 x 3.5" hot swap bats plus 3 x 2.5" internal bays. If you are going to use a few 2.5's or SSD's for say cache or apps then this would work! Very good case (with a bit of airflow control - documented below). https://lime-technology.com/forum/index.php?topic=31967.msg365137#msg365137

Update. 100% complete and no drop in speed. ~40MB/s for ALL 4TB of the files. Thats 2 tests now (1 test with ~4TB of LARGE Files of between 1.5GB and 15GB on average and peaking at about 40GB and 1 test with ~4TB of SMALLER Files of between 100MB and 400MB on average and peaking at about 2GB) in which I have NOT noticed any discernible dip in performance in these drives compared to my WD Red 3TB's. I am now convinced that these drives are more than fine for how I use Unraid and my testing has led me to feel VERY confident that I am NOT going to experience any drastically slow speeds as a result of the SMR technology and the persistent cache implemented in these drives. So much so that I am not abandoning my plan to use WD PMR drives in my Main Server for these Seagate's (AUD $399 for a WD Red 6TB vs AUD $399 for a Seagate 8TB Archive which performs just the same in my use case - No Brainer). As noted earlier I am working to put this all into a Sticky and bring it all together. More than happy!

You read my mind. I PM'd garycase only an hour or so ago about it - more about format and what to include and see if we can sticky it. Too much wine tonight to do it now and the latest test still has ~ 2 hours to run! I'm on it though! I'll take the action!!

@pras1011: Thats good enough for me! Unless you can think of a reason I should run a test not addressed here - not going to bother!

I know I am beginning to sound like a one string banjo when it comes to addressing issues and future development of Unraid but I feel I must keep plucking .... Since I have started using v6bx - one of the things I am most disappointed about is that the webGui does not yet provide the full S.M.A.R.T report meaning I have to drop to the command line when I want to get this data as documented in the Wiki (http://lime-technology.com/wiki/index.php?title=Troubleshooting#Obtaining_a_SMART_report). Once again I repeat - LT's position is that they only want and expect the ADVANCED user to drop to the command line (which has been used as an argument for not implementing other features) HOWEVER obtaining a FULL S.M.A.R.T report is essential when dealing with a failing / failed drive which EVERY user of Unraid will experience. Why didn't the implementation of this feature go ALL the way and present the FULL report on the GUI? Just for interest - what do you think is missing from the current information displayed by the GUI? As far as I can see it is all there under the Disk Health tab albeit split over several dialogs. This does not mean it cannot be improved. Obvious enhancements include: Adding a button to download the complete report Giving some history of the SMART attributes so you can see change over time Hi! I was referring to my ability to capture a FULL report that I could post on the forum for support (which ultimately is what I and probably most other users would do in the event of an issue). The data presented when you click the drive link in the GUI is quite comprehensive. Maybe I have had too much Red wine tonight (Saturday night here in AUS ) .... Sorry if I wasn't clear. Might have to stop drinking - or posting!

http://lime-technology.com/forum/index.php?topic=39343.msg368427#msg368427

Ah! Clearer now! Ta! If you don't check out anything else in my thread check out this: http://www.caselabs-store.com/hdd-cage-assy-standard/ The expansion HDD Cage I chose for the R5 for 4 additional drives. Being able to mount this on the 120mm fan holes on the bottom of the case next to the existing drive cages and have space for 4 more 3.5” drives is awesome. I saw some Caddy’s which were ok but non of this quality. Shame about having to get it shipped from US for me living in AUS but I feel it was worth i without a doubt.

Yep. Note: that I run the preclears for all 3 drives in Parallel within a separate tty using the bmi interface provided by the ASRock board (benefits of Server grade H/W ). But you could achieve the same using SCREEN.