shooga

Thanks @Squid. I understand your logic here and it makes sense. I am using xfs on my array and btrfs on my cache pool. I will try changing the backup setting to use a single disk. I am also trying to space out my scheduled mover and backup times, just to make sure they are not running at the same time. I guess it's worth mentioning that I was just deleting some old backup data and when I used rm -r on the plex directory it took ~10 minutes and my GUI was unresponsive for part of that. It did come back though. The hang I see when backing up seems to last indefinitely, but the behavior is similar.

The log file info that you used to troubleshoot your issue.

I've been having trouble on and off with this too. It seems to work fine when I do a manual backup, but sometimes the automated backups seem to hang and cause the server to become non-responsive. I'm also backing up my Plex directory, but that's one of the main things I want to back up, so I don't want to exclude it. @thaddeussmithAre you just looking at the system log? Does that persist past the forced reboot? I'm unable to access the server when mine hangs and couldn't get to the log file.

@Squid I'm having problems with the Backup and Auto-Update plugins too. After using them for many months with no issues, I've had two consecutive weeks where my server has become totally unresponsive (requiring a long power button press) when doing my weekly backup and update. WebGUI won't load, can't SSH in. I've disabled both for now. What's the best way to troubleshoot this?

Ok, thanks. That makes sense. I'll give included/excluded a try.

It looks like the Cache Dirs plugin is preventing several of my drives from spinning down. I used the Open Files plugin to figure out that a find process was the only thing accessing the drives and after some forum searching realized that Cache Dirs might be the culprit. Sure enough, the drives seem to stay spun down after disabling Cache Dirs. Is this a known issue? Or there any fixes or workarounds? I installed it long ago and didn't used to have this problem. I believe I'm using the default settings. I'm on version 6.3.2.

Might be a dumb question, but here goes: I've been running this a while and it works great. I originally imported from PlexWatch so I have that old config folder (and database) as a path. That was just needed for import right? I can remove that path and delete the files right? Thanks!

I'm trying to get this up and running with just the wemo plugin for now, but am getting an error: [12/4/2016, 8:30:30 AM] ERROR LOADING PLUGIN homebridge-platform-wemo: [12/4/2016, 8:30:30 AM] Error: Plugin /usr/lib/node_modules/homebridge-platform-wemo requires a HomeBridge version of >=0.4.1 which does not satisfy the current HomeBridge version of 0.3.4. You may need to upgrade your installation of HomeBridge. I assume this means that the image needs an update.

Thanks trurl. That seems to have solved it. I figured it was probably something basic that I was overlooking.

Thanks for the response. I don't think it's writing to the docker image because of the folder that I see at /mnt/disks/, which isn't mapped to a drive but is just a regular folder with the Crashplan data in it. My docker settings are attached. I need to head to work and don't have Crashplan running at the moment (I removed it while troubleshooting), but I was backing up to a folder on the USB drive (supposedly) that only showed up after mounting with unassigned devices. I browsed to it via /unassigned. It seems like the Crashplan docker saw the mounted drive and then for some reason created a folder with the same name rather than writing to the drive itself. Not sure if it matters, but the drive is vfat.

I'm having an issue that I see reported by other users on this thread, but I don't see any resolution. I'm going to have a friend host a drive for me as remote backup and want to seed the drive (external USB) with data before setting it up at his place. I connect it and mount with unassigned devices. I have the paths set correctly in the docker setup (/unassigned -> /mnt/disks/) and it seems like it is setup correctly as it sees the drive. However, when I start the backup it runs out of space at about 4GB even though the drive has nearly 1TB free. I also can browse the drive in the terminal and don't see the folder that Crashplan has created. So it must be backing up somewhere else. Here's where it gets weird. I removed the docker container and unmount the drive, then take a look at /mnt/disks/ again, and the folder that the drive is mounted to is still there. Then when I look in that folder, I see the folder that Crashplan created and was backing up to. If I mount the drive again then I see the first version of the folder (which I think is the physical drive). So it seems like Crashplan is behaving as if the drive isn't mounted and just writing to a regular folder instead of the drive. Like there are duplicates or something. Any idea what's happening here and how I can fix it? Also, I assume this data is being written to the flash drive right? The UNRAID dashboard doesn't show the usage on the flash drive growing.

I'm curious how people are using this. I think the ideal scenario is that I would backup my computers to my file server and then use Crashplan on the file server to provide a remote backup of everything. Then you can use the single PC Crashplan account. However, it doesn't seem like using Crashplan for the local backup is a great idea because then you have nested Crashplan backups and would need to recover twice to get the files back right? Just seems like that adds another layer of risk. However, it would be simpler to use if I was just using Crashplan everywhere. Perhaps it would be better to use something like a folder sync (maybe Carbon Copy Cloner on a mac) to do the local backup? Then you just have the raw files to backup with Crashplan. I'm thinking of my Music and Photos folders in OS X for example and would just sync them with user shares. What are people's strategies here? Thanks!

An update for anyone monitoring this thread or searching in the future: I used the command "docker exec -it <container name> bash" to drop into the container and then this, "find / -xdev -type f -size +100M" to find files over 100MB. This helped me find that I had a 1.34GB error log in three of my containers! (eroz's AirVideoServer, needo's PlexMediaServer, and needo's PlexWatch). Deleting that file is an easy temporary fix, but I still need to figure out a long term solution. Any idea what would be causing this error: Nov 1 08:10:18 [server name] sshd[435]: error: Bind to port 22 on 0.0.0.0 failed: Address already in use. Nov 1 08:10:18 [server name] sshd[435]: fatal: Cannot bind any address. I'm guessing it's because ssh is already open on the server. How could I fix this?

I took a look and didn't have any dangling images, so that didn't help. Is there a way to view the image sizes? cAdvisor seems to only report the size of the default image because if I add up the numbers that it shows the total is way short of what shows in my docker settings page.

I have this issue too and have all of my temp folders for sabnzbd and plex pointing outside docker to my cache. I've already expanded by docker image once and would like to avoid doing that repeatedly. Need to find a solution here.

I think I found a bug in the Fan Auto Control plugin, but it's actually working as a feature for me - so please don't fix it unless you add a feature that allows the exclusion of certain drives from the temperature check. I just switched to an mSATA SSD cache drive and (eventually) noticed that the high temp it's reporting in the UNRAID dashboard isn't causing my fans to spin faster. I took a look at the source for the plugin and see that you are using grep to find the Temperature_Celsius attribute from the output of smartctl. However, manually running that command on my SSD returns nothing because this drive doesn't report temperature using the Temperature_Celsius attribute and instead uses the Airflow_Temperature_Cel attribute. This drive is a 500GB Samsung 850 EVO mSATA SSD and I bet there are other drives out there that report temperature in the same way via smartctl. So to fix this I think you could just modify the plugin so that if grep for Temperature_Celsius returns nothing then you look for Airflow_Temperature_Cel. However, in my case my SSD is running a bit hot and more importantly is not near the array drives/fans so it really shouldn't be driving the fan speed (unless it was a different fan). So if you do fix this please add the option to exclude a drive (or drives) from the temp check so they don't affect fan speed. I think it would be good for other people too because I see lots of people moving to SSD cache drives and PC cases often have the SSDs mounted in entirely different locations.

I successfully moved from rfs to xfs using the process and commands from this thread. Thanks for the great info. Specifically, I used: rsync -av --progress --remove-source-files /mnt/diskX/ /mnt/diskY/ >rsync.log 2>rsync.err Those last two arguments (>rsync.log 2>rsync.err) send the output and errors to separate log files, which I monitored using the tail command: tail -f filename.ext I did this all in three screen sessions (one for the rsync and one for each tail command). Worked great and I was able to follow the progress while also capturing the output in case anything went wrong and I needed to refer to it later. Thankfully, there were no errors.

Is there a list of motherboards that are known to work with System Temp and System AutoFan? Also, what temp would be used to drive chassis fans and can this be adjusted? Edit: I was able to get this working based on a procedure on this thread. My motherboard only has one 4pin fan connector (CPU fan) so I'd still like to know if there's a list because AutoFan seems to only work with PWM. Which temp in SystemTemp is AutoFan using? Can anyone give any guidance on what the following temps are? These are my choices in System Temp: coretemp - Physical id 0 - 44.0 C coretemp - Core 0 - 45.0 C coretemp - Core 1 - 43.0 C coretemp - Core 2 - 45.0 C coretemp - Core 3 - 43.0 C w83627ugh - SYSTIN - 51.0 C w83627ugh - PECI Agent 1 - 44.0 C The coretemps are pretty obvious except for the Physical id 0. No idea where the w83627ugh temps would be measured though. Is PECI coming from the CPU? SYSTIN would be the motherboard? I'd be surprised if the motherboard is hotter than the CPU.

Is there any reason to do a clean install vs using this upgrade plugin (other than the upgrade might fail)? I have a ~3 year old 5.0-rc11 server that I'm finally ready to update. I have several plugins, packages, customized go script, etc. The only thing I'd like to keep is my config, otherwise I want to switch to docker and get back to as clean an install as possible. This plugin will give me a clean install with only my array/shares config carried over right? All of my other plugins/packages/customizations will be removed? I have two identical USB thumb drives, so I would make a backup and have a fail safe either way. Thanks!

Ok, cool. Thats good news. Thanks Rob!

Ok, good to hear. I'm new to reading SMART results. I was concerned about the End_to_End_Error and Spin_Retry_Count as they are both very close to the threshold.

This is an old drive and I see a couple attributes that are near the threshold. Should it be retired? Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: SMART Attributes Data Structure revision number: 10 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: Vendor Specific SMART Attributes with Thresholds: Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 1 Raw_Read_Error_Rate 0x000f 117 099 006 Pre-fail Always - 137310847 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 3 Spin_Up_Time 0x0003 096 095 000 Pre-fail Always - 0 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 98 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 7 Seek_Error_Rate 0x000f 075 060 030 Pre-fail Always - 34750361 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 9 Power_On_Hours 0x0032 071 071 000 Old_age Always - 26180 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 48 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 184 End-to-End_Error 0x0032 100 100 099 Old_age Always - 0 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 189 High_Fly_Writes 0x003a 056 056 000 Old_age Always - 44 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 190 Airflow_Temperature_Cel 0x0022 070 059 045 Old_age Always - 30 (Min/Max 22/33) Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 194 Temperature_Celsius 0x0022 030 041 000 Old_age Always - 30 (0 19 0 0) Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 195 Hardware_ECC_Recovered 0x001a 053 048 000 Old_age Always - 137310847 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 2 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: SMART Error Log Version: 1 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: No Errors Logged Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: SMART Self-test log structure revision number 1 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: No self-tests have been logged. [To run self-tests, use: smartctl -t] Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: SMART Selective self-test log data structure revision number 1 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 1 0 0 Not_testing Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 2 0 0 Not_testing Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 3 0 0 Not_testing Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 4 0 0 Not_testing Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 5 0 0 Not_testing Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: Selective self-test flags (0x0): Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: After scanning selected spans, do NOT read-scan remainder of disk. Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: If Selective self-test is pending on power-up, resume after 0 minute delay. Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: == Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: ============================================================================ Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: Mar 4 16:27:45 Bunker last message repeated 2 times Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: ============================================================================ Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: == Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: == S.M.A.R.T Final Report for /dev/sda Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: == Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: Disk: /dev/sda Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: smartctl 5.40 2010-10-16 r3189 [i486-slackware-linux-gnu] (local build) Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: === START OF INFORMATION SECTION === Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: Model Family: Seagate Pipeline HD 5900.2 family Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: Device Model: ST31000322CS Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: Serial Number: 9VX0JHEY Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: Firmware Version: SC13 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: User Capacity: 1,000,204,886,016 bytes Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: Device is: In smartctl database [for details use: -P show] Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: ATA Version is: 8 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: ATA Standard is: ATA-8-ACS revision 4 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: Local Time is: Mon Mar 4 16:27:43 2013 PST Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: SMART support is: Available - device has SMART capability. Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: SMART support is: Enabled Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: === START OF READ SMART DATA SECTION === Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: SMART overall-health self-assessment test result: PASSED Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: General SMART Values: Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: Offline data collection status: (0x00)^IOffline data collection activity Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: ^I^I^I^I^Iwas never started. Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: ^I^I^I^I^IAuto Offline Data Collection: Disabled. Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: Self-test execution status: ( 0)^IThe previous self-test routine completed Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: ^I^I^I^I^Iwithout error or no self-test has ever Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: ^I^I^I^I^Ibeen run. Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: Total time to complete Offline Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: data collection: ^I^I ( 633) seconds. Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: Offline data collection Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: capabilities: ^I^I^I (0x73) SMART execute Offline immediate. Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: ^I^I^I^I^IAuto Offline data collection on/off support. Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: ^I^I^I^I^ISuspend Offline collection upon new Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: ^I^I^I^I^Icommand. Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: ^I^I^I^I^INo Offline surface scan supported. Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: ^I^I^I^I^ISelf-test supported. Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: ^I^I^I^I^IConveyance Self-test supported. Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: ^I^I^I^I^ISelective Self-test supported. Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: SMART capabilities: (0x0003)^ISaves SMART data before entering Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: ^I^I^I^I^Ipower-saving mode. Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: ^I^I^I^I^ISupports SMART auto save timer. Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: Error logging capability: (0x01)^IError logging supported. Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: ^I^I^I^I^IGeneral Purpose Logging supported. Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: Short self-test routine Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: recommended polling time: ^I ( 1) minutes. Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: Extended self-test routine Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: recommended polling time: ^I ( 215) minutes. Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: Conveyance self-test routine Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: recommended polling time: ^I ( 2) minutes. Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: SCT capabilities: ^I (0x103b)^ISCT Status supported. Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: ^I^I^I^I^ISCT Error Recovery Control supported. Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: ^I^I^I^I^ISCT Feature Control supported. Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: ^I^I^I^I^ISCT Data Table supported. Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: SMART Attributes Data Structure revision number: 10 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: Vendor Specific SMART Attributes with Thresholds: Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 1 Raw_Read_Error_Rate 0x000f 109 099 006 Pre-fail Always - 24025869 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 3 Spin_Up_Time 0x0003 096 095 000 Pre-fail Always - 0 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 98 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 7 Seek_Error_Rate 0x000f 075 060 030 Pre-fail Always - 34834273 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 9 Power_On_Hours 0x0032 071 071 000 Old_age Always - 26233 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 48 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 184 End-to-End_Error 0x0032 100 100 099 Old_age Always - 0 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 189 High_Fly_Writes 0x003a 056 056 000 Old_age Always - 44 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 190 Airflow_Temperature_Cel 0x0022 068 059 045 Old_age Always - 32 (Min/Max 22/33) Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 194 Temperature_Celsius 0x0022 032 041 000 Old_age Always - 32 (0 19 0 0) Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 195 Hardware_ECC_Recovered 0x001a 053 048 000 Old_age Always - 24025869 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 2 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: SMART Error Log Version: 1 Mar 4 16:27:45 Bunker preclear_disk-diff[8976]: No Errors Logged

Noticed these errors in my log during preclear. Does this indicate a controller problem? Edit: Realizing that this is actually my cache drive, not one being precleared. Also realizing that I used a cable on the cache drive that may not be compatible with SATAII or SATAIII (it came with a SATAI controller). Could this be the issue? Mar 3 19:09:00 Bunker kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Mar 3 19:09:00 Bunker kernel: ata4.00: failed command: WRITE DMA EXT Mar 3 19:09:00 Bunker kernel: ata4.00: cmd 35/00:00:d0:4c:09/00:04:45:00:00/e0 tag 0 dma 524288 out Mar 3 19:09:00 Bunker kernel: res 40/00:00:01:4f:c2/00:00:45:00:00/10 Emask 0x4 (timeout) Mar 3 19:09:00 Bunker kernel: ata4.00: status: { DRDY } Mar 3 19:09:00 Bunker kernel: ata4: hard resetting link Mar 3 19:09:05 Bunker kernel: ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 310) Mar 3 19:09:05 Bunker kernel: ata4.00: configured for UDMA/100 Mar 3 19:09:05 Bunker kernel: ata4: EH complete Mar 3 19:10:18 Bunker kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Mar 3 19:10:18 Bunker kernel: ata4.00: failed command: WRITE DMA EXT Mar 3 19:10:18 Bunker kernel: ata4.00: cmd 35/00:00:d0:b4:0a/00:04:45:00:00/e0 tag 0 dma 524288 out Mar 3 19:10:18 Bunker kernel: res 40/00:00:01:4f:c2/00:00:45:00:00/10 Emask 0x4 (timeout) Mar 3 19:10:18 Bunker kernel: ata4.00: status: { DRDY } Mar 3 19:10:18 Bunker kernel: ata4: hard resetting link Mar 3 19:10:23 Bunker kernel: ata4: link is slow to respond, please be patient (ready=-19) Mar 3 19:10:24 Bunker kernel: ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 310) Mar 3 19:10:24 Bunker kernel: ata4.00: configured for UDMA/100 Mar 3 19:10:24 Bunker kernel: ata4: EH complete Mar 3 19:11:08 Bunker kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Mar 3 19:11:08 Bunker kernel: ata4.00: failed command: WRITE DMA EXT Mar 3 19:11:08 Bunker kernel: ata4.00: cmd 35/00:00:48:ca:0b/00:04:45:00:00/e0 tag 0 dma 524288 out Mar 3 19:11:08 Bunker kernel: res 40/00:00:01:4f:c2/00:00:45:00:00/10 Emask 0x4 (timeout) Mar 3 19:11:08 Bunker kernel: ata4.00: status: { DRDY } Mar 3 19:11:08 Bunker kernel: ata4: hard resetting link Mar 3 19:11:13 Bunker kernel: ata4: link is slow to respond, please be patient (ready=-19) Mar 3 19:11:18 Bunker kernel: ata4: COMRESET failed (errno=-16) Mar 3 19:11:18 Bunker kernel: ata4: hard resetting link Mar 3 19:11:23 Bunker kernel: ata4: link is slow to respond, please be patient (ready=-19) Mar 3 19:11:28 Bunker kernel: ata4: COMRESET failed (errno=-16) Mar 3 19:11:28 Bunker kernel: ata4: hard resetting link Mar 3 19:11:30 Bunker kernel: ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 310) Mar 3 19:11:30 Bunker kernel: ata4.00: configured for UDMA/100 Mar 3 19:11:30 Bunker kernel: ata4: EH complete Mar 3 19:12:01 Bunker kernel: ata4.00: limiting speed to UDMA/66:PIO4 Mar 3 19:12:01 Bunker kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Mar 3 19:12:01 Bunker kernel: ata4.00: failed command: WRITE DMA EXT Mar 3 19:12:01 Bunker kernel: ata4.00: cmd 35/00:00:48:e2:0b/00:04:45:00:00/e0 tag 0 dma 524288 out Mar 3 19:12:01 Bunker kernel: res 40/00:00:01:4f:c2/00:00:45:00:00/10 Emask 0x4 (timeout) Mar 3 19:12:01 Bunker kernel: ata4.00: status: { DRDY } Mar 3 19:12:01 Bunker kernel: ata4: hard resetting link Mar 3 19:12:06 Bunker kernel: ata4: link is slow to respond, please be patient (ready=-19) Mar 3 19:12:11 Bunker kernel: ata4: COMRESET failed (errno=-16) Mar 3 19:12:11 Bunker kernel: ata4: hard resetting link Mar 3 19:12:16 Bunker kernel: ata4: link is slow to respond, please be patient (ready=-19) Mar 3 19:12:21 Bunker kernel: ata4: COMRESET failed (errno=-16) Mar 3 19:12:21 Bunker kernel: ata4: hard resetting link Mar 3 19:12:26 Bunker kernel: ata4: link is slow to respond, please be patient (ready=-19) Mar 3 19:12:56 Bunker kernel: ata4: COMRESET failed (errno=-16) Mar 3 19:12:56 Bunker kernel: ata4: hard resetting link Mar 3 19:13:00 Bunker kernel: ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 310) Mar 3 19:13:02 Bunker kernel: ata4.00: configured for UDMA/66 Mar 3 19:13:02 Bunker kernel: ata4: EH complete

I haven't tie wrapped any cables together...but I'll admit that I was tempted to do that before closing my case. I'll make sure I don't and will re-route SATA cables to spread them out a bit more. I went back and double checked my log and don't see any other CRC errors, so hopefully it's not a power issue. What's the best way to keep an eye on this? Just check the log periodically while using the drives? Should I preclear again with a new cable to test? Do the bad sectors indicate a drive that is nearing end of life? Is it still worth adding these to my array? The SATA controller card is from Monoprice and it's SATA I, so yes it's slow. I think it'll be fast enough for my media streaming and I do have a cache drive to help with write performance. Thanks again for all the info guys. I really appreciate that the unRAID community is so responsive and helpful. I definitely have a lot to learn.

Thanks Rob. Which error indicates the bad cable? These drives are connected via a 4 port SATA card. Could that have something to do with it? (I haven't noticed errors for the other two drives on that card though.)