you everyone for the help with choosing my hardware. I was finally able to put the system together over the weekend and I have a few questions. The new Motherboard: GIGABYTE GA-MA785G-UD3H and raid cards seem to work. All the hard drives are being recognized. I’m also happy to report that HPA is not present and any of the drives. 

 

I opened up 5 putty sessions (one for each drive) and started Joe’s preclear_disk.sh script.

 

Question #1

Two of the drives had an error (see attached). Should this be a concern? I installed unMENU and installed/enabled the powerdown script. I also added “sysctl -w kernel.poweroff_cmd="/sbin/powerdown" to the end of my go script. The power button hook seems to work.

 

Question #2

How do I evoke this (sorry if this is dumb)? There was already a “powerdown” command in root before I even installed unMenu. Is this the same?

 

I installed cache_dirs v1.6.1 script and added the following line to my go file /boot/cache_dirs  -d  5  -m  3  -M  5  -w

 

Question #3

Using the following parameters for the cache_dirs script, it will scan the directories between 3 and 5 seconds. Won’t this keep the drives spinning because they are constantly being scanned? I have some folders with 1000’s of files inside them. It would best to exclude these, right? I have 2 gigs of RAM and roughly 3TB of data.

 

Question #4

How can I see my transfer speed? I use SyncBack SE to synchronize my backups and its estimating 28hrs for 384gigs. It’s going to take a week to transfer 3TB. Is this normal? I want to note that I have not assigned a parity drive while I copy the files initially.

 

Question #5

When I reboot, I always get the following line in my Syslog: Sep 28 12:40:21 unraid unmenu[1357]: ls: cannot access /boot/custom/etc/rc.d/*: No such file or directory

 

Question #6

Is there a way to clean restart the server instead of powering down and then turning it back on?

Q1.

 

Assuming the drives are Seagate drives the seek error rate can be safely ignored.

 

I also have one seagate drive where the UDMA error count occasionally increases, there is a corresponding error in the syslogs. This is indicative of a cabling error, I have ordered a new set of cables for the new MB that is due to be fitted after some more testing. If you have a spare cable try swapping out the cable or re-routing it.

 

Q3.

 

No, that is very slow. I transferred 2 TB in about 24 hours over Gb.

 

Try turning off cache_dirs whilst transferring data and write to the disk shares if possible.

Q1: There are no errors in either of the SMART listings.  In fact, there are almost no changes, just the Load_Cycle_Count increases by 1, which is expected.  The others are zero, before and after.  I would like to ask Joe to consider dropping more of the SMART attributes (such as Load_Cycle_Count), as they needlessly alarm users.  I would also request that in the comparison of before and after, if one of the numbers is 253 and the other is either 100 or 200, then there is no change at all.  This would drop a number of spurious changes, such as 3 of the 4 above.

 

Q4: One possible factor, SyncBack may be configured to verify the copies, which will add considerable time to the copying.  That still does not account for how slow it is being projected, so I would obtain and attach your syslog, please see the Troubleshooting link in my sig.  It should show why your speeds are so slow.

 

Q6: From the unRAID Web Management page, when you Stop the array, you will see a button for Rebooting the server.

Kaygee

Q1: /sdc is a seagate 500gig where /sde is a brand new WD 1.5TB green drive.

 

Q: I didn't have Dir Cache enabled at the time and I am writing directly to /IP/disk#/Share. Plus I don't think my ASUS 500g V2 is gigabit 

 

 

RobJ

Q4: I do use the option to verify the file has been copied in SyncBack. I know this will had some overhead, but every since I had a file corruption during my backup, I figure its better to be safe than sorry.

 

Q6: Ok, but can a restart be evoked though telnet?

Q4: One possible factor, SyncBack may be configured to verify the copies, which will add considerable time to the copying.  That still does not account for how slow it is being projected, so I would obtain and attach your syslog, please see the Troubleshooting link in my sig.  It should show why your speeds are so slow.

Estimated time was cut in half when I turn off verify files. I will copy the bulk over and then do a deep verify on the files to make sure they are the same.

 

Attached syslog. Where does it say my transfer speed?

Your syslog looks fine, I don't see any real problems or bottlenecks.  Syslogs don't actually show transfer speeds.  We check them to see if the kernel was able to set up everything correctly, then check if there are sequences of errors for any drives.  In the drive setup, we want to see each drive with a SATA link up at 3.0 Gbps (but 1.5 Gbps won't really matter).  We then want to see a UDMA mode of UDMA/133 or UDMA/100.  And we don't want to see any errors, not only because errors are bad(!), but because they usually involve repeated pauses, which really slow things down.

 

The next thing to check is your network speed.  Many network drivers report the speed of the connection, but yours did not, so please see the Console Commands for Networking section.  I believe the third command will show you your network connection speed.  If you have gigabit hardware, you want to see 1000 Mb/s.  If you are only seeing 100 Mb/s, then you were not able to negotiate a gigabit connection, and that would explain why the transfers are so slow.  A gigabit connection requires gigabit network support at both ends of the connection, a gigabit router or switch, and gigabit-quality cables.

 

By the way, you may be interested in the Improving unRAID Performance wiki page.

Q4: I do use the option to verify the file has been copied in SyncBack. I know this will had some overhead, but every since I had a file corruption during my backup, I figure its better to be safe than sorry.

I strongly prefer the verify option myself, even if it takes longer.

 

Q6: Ok, but can a restart be evoked though telnet?

It really is preferable to use the Web Management page, so that everything is correctly closed down before rebooting.  It is possible to do that from a command prompt, probably with a version of the powerdown script, but offhand I don't remember anyone doing that.

The SMART data is being shown because worst values changed from 200 to 253. This is expected behaviour with Seagate drives.

My Samsungs dont do it, nor do my WD drives (my only excuse for owning WD is they were on special), at least I havnt seen them do it.

 

IMO I like the way preclear script works. If someone doesnt know or is unsure they can ask. Better safe than sorry, also more people will post up their results giving the forum readers more chance to look at result logs. Just my 2c.

 

Plus I don't think my ASUS 500g V2 is gigabit

 

Realtek RT8169 is a Gb nic. System Info/Ethernet Info or ethtool eth0 at the console will show connection information. 

 

 

Could someone explain what these SysLog events mean?

 

*Red* - Errors

Sep 30 17:41:41 unraid sshd[3921]: error: Could not get shadow information for root

Sep 30 11:55:22 unraid kernel: atiixp 0000:00:14.1: simplex device: DMA disabled

Sep 30 11:55:22 unraid kernel: ide1: DMA disabled

 

*Black*

Sep 30 11:55:25 unraid kernel: can't shrink filesystem on-line

 

 

What does the mover script do?

*Red* - Errors

Sep 30 17:41:41 unraid sshd[3921]: error: Could not get shadow information for root

This is only found in connection with sshd, which is not included with unRAID.  Perhaps someone who is familiar with ssh can help you.  It appears to be harmless, just informational.

 

I would caution you that the Syslog Viewer in UnMENU was an early effort of mine to help users unfamiliar with reading syslogs.  It was an attempt to highlight and categorize the most useful information.  It however needs updating, and was never very intelligent in some circumstances, such as this.  The existence of the word 'error' causes a line to be red-flagged, but is clearly not specific enough about the messages it highlights.  Some errors are truly errors, others are only informational messages, and in some cases not errors at all.  For example, lines with "errors: 0" or "no errors found" do contain 'error', so would wrongly be in red.  This color coding was designed to be helpful, but should not be completely relied on.  Common sense is always necessary.

 

Sep 30 11:55:22 unraid kernel: atiixp 0000:00:14.1: simplex device: DMA disabled

Sep 30 11:55:22 unraid kernel: ide1: DMA disabled

This message is only reported by the atiixp module (controls a particular set of IDE ports), and just indicates that DMA will not be used.  It *may* be because DMA is not enabled in the BIOS set for those IDE ports.  It obviously should not be highlighted, not sure why it was.

 

Sep 30 11:55:25 unraid kernel: can't shrink filesystem on-line

Very normal, appears at the completion of every successful mount of a Reiser file system in unRAID syslogs

 

What does the mover script do?

There is some description here:  the Mover script