Disk at 50C or spin down the disks?

[Davvo]

and because the disks makes a "clunk" noise every 5 seconds which can drive anybody crazy.

I believe that disks shouldn't make that kind of noise. Make sure they are not spinning up and down every 5 seconds.

 

[ragametal]

I believe that disks shouldn't make that kind of noise. Make sure they are not spinning up and down every 5 seconds.

They only do the clunk noise every 5 seconds when i have them spinning 24x7, so it might be their PWL "feature". They don't do it when they are set to spin down but that is a conversation for another thread (which I'm about to start).

 

[Davvo]

They only do the clunk noise every 5 seconds when i have them spinning 24x7, so it might be their PWL "feature".

WD disks doing WD things...

 

[joeschmuck]

In the end I used the noctua NA-FC1 pwm fan controller as suggested by @Davvo . The Fans now stay in the low 40C even when they are under heavy use which is perfect for me because they experience very little temperature change and they are more than 20C below their max spec limit.

Great to hear! Did the fan sound level increase?

Now that my disks don't go above 42C under heavy use, i may consider putting them to sleep as well. This time to save energy (because somebody else will pay for the electricity of this system) and because the disks makes a "clunk" noise every 5 seconds which can drive anybody crazy.

I would recommend against that. You only have two drives which consume 4.1 watts each at idle, .4 watts each when sleeping (3.7 watts diff) so a total of 7.4 watts saved if you sleep them. Now compare that to the possibility of the spindle motor electronics dying. The NAS itself consumes 8.1 watts of power alone, which is actually pretty darn good, call me impressed. So I'd recommend leaving the drives running if power consumption/price is your concern. If you do sleep them, periodically check the startup count, make sure they are not waking up too often. Computers on the network can poll the network and get the NAS to spin the drives back up, just for a status only.

And thanks for updating the thread.

 

[joeschmuck]

hey only do the clunk noise every 5 seconds when i have them spinning 24x7

Check the Load_Cycle_Count on the drives. See if that value is incrementing. Fast incrementing is cause for notice and to find out if it's too much, slow incrementing (maybe 5 to 24 in a 24 hour period) is good. Mine never increment unless the drive is powered off, the way I like it.

 

[ragametal]

@joeschmuck , the noise level of the fan is very acceptable. About the Clunk noise, i have the drives spinning 24x7 at the moment and the Load_Cycle_Count hasn't change.

 

[ragametal]

@joeschmuck , to be more specific, the smartctl -A /dev/ada1 reports the following

Code:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  3 Spin_Up_Time            0x0007   083   083   001    Pre-fail  Always       -       342 (Avera
  4 Start_Stop_Count        0x0012   100   100   000    Old_age   Always       -       23
  9 Power_On_Hours          0x0012   100   100   000    Old_age   Always       -       547
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       15
193 Load_Cycle_Count        0x0012   100   100   000    Old_age   Always       -       43

and smartctl -A /dev/ada0 shows the following

Code:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  3 Spin_Up_Time            0x0007   083   083   001    Pre-fail  Always       -       340 (Average 352)
  4 Start_Stop_Count        0x0012   100   100   000    Old_age   Always       -       22
  9 Power_On_Hours          0x0012   100   100   000    Old_age   Always       -       547
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       13
193 Load_Cycle_Count        0x0012   100   100   000    Old_age   Always       -       42

As you can see, i have very low Load_Cycle_Counts in 547 hours (3 weeks).

BTW, the idea to put the drives to sleep was not necesarily to save power, it was more to eliminate this noise.

 

[joeschmuck]

Those are great looking values.

BTW, the idea to put the drives to sleep was not necesarily to save power, it was more to eliminate this noise.

Yes, some drives are noisier than others and I do understand, which is why my server use to be in the basement, then I moved and now it's in the Loft. The only thing I can hear is when I have a power outage, the UPS beeps, well all of my UPS's beep. Drives me crazy when the power outage lasts for a few hours because I have to run around and manually turn them off even though the NAS powered down already.

On a different topic, I'd be curious to know what type of throughput you are getting for both a large file (~20GB) and a lot of small files (just copy an OS directory to the NAS that takes at least 30 seconds to copy, that should be good). Why do I ask? Because someone will want to replicate what you have done and desire some statistics. I know everyone would love to saturate their Ethernet cable, but most times you don't really need that and money talks.

 

[ragametal]

@joeschmuck no problem but i can't do it right now as I'm in the middle or Rsyncing my media folder from a Linux box to this sytem. But as soon as that is done i will report back with the test you requested.

In the meantime, this is the throughput of the Rsync job.

These results are extremely disappointing. I know that i don't have the latest and greatest network gear out there but everything is wired with CAT6 and directly connected tot he same 1Gb/s switch. I'm just hoping this low transfer speeds are inherent to Rsync and not a reflection of the general capabilities of this system.

I guess we will find out when this job is done, which will take several days at these speeds.

 

[Davvo]

I'm just hoping this low transfer speeds are inherent to Rsync and not a reflection of the general capabilities of this system.

Shouldn't it be the capabilities of the Linux box that's sending the files?

 

[joeschmuck]

These results are extremely disappointing.

Well there are several things that could be a factor.
1) You have a 10 MBit connection at some juncture. Seen this before on the forums more often that you would think.
2) The box sending the data is a low speed device. The Ethernet port may be 1 Gbit but the CPU, file fragmentation or just lots of small files located all over the drive(s), etc could be causing the slow down.
3) Your TrueNas machine has the same issue as #2 above, it may be 1 Gbit Ethernet but the CPU is slow, files are located all over the place.

This is why I asked for two specific tests to be done. The Large File test will tell you the maximum throughput you can expect from the system. The Small Files test will tell you a realistic throughput if you were using the NAS for active file use, such as if you were a small office and all your company files were on the NAS and people needed to use/share those files.

I'm not banking on the fact that your TrueNAS machine will be breaking any speed records, but if it serves your needs, that is what counts. I myself don't need a speed demon since mine typically is used only for backups and those backups run unattended. So if it take 15 minutes or 2 hours, it's not a big deal to me. The only issue I see with a lower performance CPU is resilvering time. When you replace a large hard drive it will take a long time to resilver if there is a lot of data present. Thankfully you only have 3TB drives so that is short compared to someone with a 16TB drive.

Also remember, you should not fill your pool above 80% or performance may be impacted, 90% and performance will be impacted as the system will change into a different mode to write data and it's slower, many of us can attest to it. I filled up my drive just to test this out, took a while but it was definitely slower at writing. Maybe things are better now, it has been many years since I tested that out. I'm at 53% full, probably never again get close to 90% again unless I rebuild my pool with less drives (a good possibility).

 

[ragametal]

@Davvo & @joeschmuck those are very good points.

Normally, the linux machine is capable of 80 MB/s which i have witnessed when copying big media files from my workstation. That linux machine has an 8 core intel avoton C2750 2.4 GHz and 8 GB of ram.

I honestly don't know about the Qnap box just yet. It has dual 2.5 Gb/s Intel NICS and Truenas 13 has the drivers for them so it should be capable of Gigabit speeds.

Both machines are wired with CAT6 directly to a Netgear JGS516 gigabit switch and, according to the blinking LEDs, both machines have gigabit connections.

All that makes me believe that the limitation here might be the processor in the Qnap as suggested by @joeschmuck . But we will know for sure when i get to do the test after the Rsync finishes. To be honest, I'll be fine if its slow as this is for remote backups and most of my data is small files and very few of them change on a daily basis.

Also, I hear you with the resilvering time (specially since these are 16 TB drives) but I'm not too concerned about it. Remember that this is a backup system. Hopefully i will never have to use this pool at all. And if i ever do, then my main focus will be to extract the data from it as soon as possible before i loose those 2 drives.

 

[ragametal]

Disregard my previous comment about the CPU being the limiting factor.
According to my stats, the CPU usage is fluctuating between 3%-5% which means that it has more than enough capacity to perform this task.

So, my issue must be somewhere in my network settings.

 

[joeschmuck]

So, my issue must be somewhere in my network settings.

This is during RSync? Could be a lot of small files, if you could check the hard drive activity, bet there are a lot of seek operations slowing it down. Also, I'm not an RSync person but my limited experience was that it was run more as a background priority, not foreground high or normal priority. So that could be part of the issue, but my first guess is drive activity slowing it down. But as you said, it could be something with the network.

 

[ragametal]

@joeschmuck turns out that rsync, while great at syncing files, is an incredibly slow tool for copying files. So, i decided to follow some advice i found online and do a regular copy just to populate the empty pool for the first time. Then i will use Rsync to copy just the files that change in the future.

I used the scp tool for this and I achieved a throughput of 85MB/s consistently (or 680Mb/s according to my napkin math). That was while copying a multitude of video files ranging from 400MB to 34GB in size.

At these speeds i was able to copy all my data in about 20 hours instead of waiting 6-7 days that Rsync would have needed.

That throughput might seem slow considering that is about 68% of the capacity of my gigabit network. However, i think the source linux machine is the limiting factor here because I have never been able to transmit data any faster to it.

I also think that the problem is the linux machine because, according to iperf, i can transmit data from my windows workstation to this TrueNAS instance at 929Mb/s which is rather good.

All in all, except for the clunking noise of the disks, I am very happy with this Qnap running TrueNAS. It is affordable (i couldn't have built anything less expensive with two 3.5" drives), it is small, quiet, the power consumption is negligible and its performance can easily saturate my internet connection. I think its the perfect target machine for remote replication tasks (at least for my use).

 

[joeschmuck]

All in all, except for the clunking noise of the disks, I am very happy with this Qnap running TrueNAS. It is affordable (i couldn't have built anything less expensive with two 3.5" drives), it is small, quiet, the power consumption is negligible and its performance can easily saturate my internet connection. I think its the perfect target machine for remote replication tasks (at least for my use).

This is a good thing. There are going to be people who want to build a small server at a less expensive price. I agree, the throughput is great and I'm actually pleased to be surprised by it. Be warned that you may be asked a few questions by new builders looking for an option like yours.

I hope the system lasts you a very long time.