Phil C.

Let me just go ahead and resolve this one - NO IT DID NOT. This is why I'm leaving unRAID. Great software, but even if you follow the instructions you'll lose your data. Not to mention lack of built-in notifications, UPS support, etc., which a lot of the community apparently feels is malware. Have fun fellas.

So, when I restarted the array as part of the process outlined in the rebuild instructions, the disk showed up as unformatted, but the rebuild was happening anyway. So the rebuild finished and the disk still shows up as unformatted. I went ahead and set it to format the drive - will this cause me to lose my data anyway or will the array figure out the data is gone and try to rebuild it again?

Thanks. I don't have a spare drive on hand, nor a spare bay to do pre-clears in...this particular server is the archive of my DVD/Blu-ray rips. Loss of the data wouldn't be catastrophic, just really inconvenient. I think I'll take a chance and rebuild onto itself if the drive doesn't clearly indicate that its bad. While I would normally follow your best advice, I'm actually looking to move away from unRAID as my file storage. Getting way too complex and needy for my limited time/skills. Investment in more hard drives for either of my servers is really undesirable. Have decided to go with a Synology rack mount solution - would rather put new drives in it. Again, appreciate your advice - will let you know how it goes to add to the body of knowledge.

Got a red ball on a drive. Here's the smart report...drive looks okay (although it is an old drive). Would appreciate an old hand's evaluation of the drive. Replace or put back into the array as is? === START OF INFORMATION SECTION === Model Family: Western Digital Caviar Green (AF) Device Model: WDC WD20EARS-00S8B1 Serial Number: WD-WCAVY2919978 LU WWN Device Id: 5 0014ee 2597ffb41 Firmware Version: 80.00A80 User Capacity: 2,000,398,934,016 bytes [2.00 TB] Sector Size: 512 bytes logical/physical Device is: In smartctl database [for details use: -P show] ATA Version is: ATA8-ACS (minor revision not indicated) SATA Version is: SATA 2.6, 3.0 Gb/s Local Time is: Sat Jun 7 11:14:22 2014 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: (0x84) Offline data collection activity was suspended by an interrupting command from host. 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: (40800) 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: ( 2) minutes. Extended self-test routine recommended polling time: ( 464) minutes. Conveyance self-test routine recommended polling time: ( 5) minutes. SCT capabilities: (0x3031) SCT Status supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0027 150 142 021 Pre-fail Always - 9500 4 Start_Stop_Count 0x0032 096 096 000 Old_age Always - 4197 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0 9 Power_On_Hours 0x0032 091 091 000 Old_age Always - 7272 10 Spin_Retry_Count 0x0032 100 100 000 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 100 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always - 1300 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 87 193 Load_Cycle_Count 0x0032 138 138 000 Old_age Always - 186453 194 Temperature_Celsius 0x0022 125 101 000 Old_age Always - 27 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 2 198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 2 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 3 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.

Sorry guys, mickey and I made the drop today. Hated to see it go - but I think it's gonna get some good use. Thanks Mickey!

Definitely still available.

I'll chime in and risk the now infamous Lime Technology Forum flames to say this: unRAID is pretty complex stuff for me already. Adding a layer of complexity such as VMs, combined with a potential need for additional memory, processing power, etc, is going to be a show stopper. I use my unRAID server as a media repository and provide an alternative location to backup some important files. I'm not curing cancer or intercepting the world's emails. While I'm certain some of you have a bona fide need to maintain absolute integrity for the unRAID OS with an absolutely clean install, I'm not sure that's the majority user case. Forced introduction of more complexity will discourage adoption by new users and likely drive off existing customers who are happy enough with the current setup - especially considering the small business nature of Lime Technology and the unpredictability of its development cycle. My two cents.

Norco 4220 server case for sale. (Gently) used. Too deep for my server cabinet. Asking $225+shipping (whatever method you want). Shipping from Chesapeake Beach, MD - happy to meet someone in the DC Metro Area to deliver. Best, Phil

Well, sh*t. I had three or four drives on hand (old but hardly used). When the parity drive failed this morning, I replaced it. That's what started this day-long extravaganza. Just changed the parity drive again - and now I'm getting 65-70 MB/s. Son of hibachi. Two bad drives in a row...and I guess that first one had been bad for a very long time - like, since I bought it. I'd scream, but it would wake the five-year-old... Thanks for the help - after doing the transfers off the data drives, I thought "Hmmmm, what if it's the parity drive, the one drive I can't copy files to/from?" Phil C.

I appreciate the help. I have changed cables. I do have a gigabit network - although right now, the server is on an airport express (802.11n) because I had to relocate it out of my basement server room to work on it. Server was on the gigabit network when I had the initial problem. I tried to copy a file from each drive. Files were from 400 to 600MB each. All exhibited approximately the same data rate (completion in 2-3 minutes, difference being what I expected based on difference in file size). So no sore thumb stuck out. Of course, it could be that the wireless is slow enough to mask I/O differences...is that possible? Please keep it coming.... Thanks, Phil

I'm hoping someone can help. I have an unRAID server that I built in 2010, basically my home version of the one sold by Lime Technology at the time. Supermicro C2SEA motherboard, Icy Dock cages, 7 drives (now) mostly Seagate 1.5 TBs. I had a Promise SATA300TX4 Controller, but swapped it for a Supermicro AOC-SASLP-MV8. I have flashed the MB to the latest BIOS, as well as the latest firmware for the SASLP-MV-8. Can't get the Promise controller updated - Just too hard to do booting from a USB flash drive with no floppy or CD-ROM. Anyway, the server has ALWAYS been slow. Parity checks less than 10Mb/s that take 5 and 6 days to complete, but I just lived with it because I didn't know any better. In the meantime I built a new server to handle media service, and relegated the "old" one to being an archive. Yesterday my parity drive started having write errors. I had a spare drive (WD 2Tb) so I put it in. Parity-sync started - and its going at <5Mb/s. It will take over a week for this to complete. I let it run for most of today (~8 hours) and it got up to 1.5%. Just for comparison, I fired up a parity check on my new server; it's running at 95Mb/s. It will be done in no time. The new server shows nearly constant disk activity on all the disks at once; the "old" server shows constant activity on the parity drive, but only flashes activity on all the others. I have changed all the cables, changed back to the Promise controller, checked all the BIOS settings - I have done everything I know to do. I even rolled the unRAID software back to 15A. Nothing helps. I've attached a syslog for the server, about 20 minutes into parity-sync under RC-16c. Don't know if it will help but maybe. Would appreciate any ideas anyone has. Phil C. syslog-2013-07-13.txt

I don't have a cache drive at all...so dunno if cache_dir is running - I assume it isn't. I don't run SimpleFeatures either.

Abandon hope, all ye who enter here...I'm running RC8a and I still get the same thing. Drives are spinning up on their own every twenty minutes or so, prompted by (I think) Netatalk. The spindowns are just unRAID doing its job. Hoping Netatalk gets updated to 3.0 in the final, and that it will finally fix the problem. It really sucks because it heats up the drives, increases energy consumption and wears them faster than they might otherwise. Oh well...

I have two unRAID servers in an all Mac house. My primary server (the one in my sig) runs 24/7 and all five shares are mounted via AFP to my Mac Mini server. I run Plex Media Server on the Mac Mini. I have never once had an access or special character problem, although I have never used the " | " character. My primary server is highly reliable, running the latest RC. I think Netatalk is keeping my drives from staying spun down, but it's never a connection issue. My secondary server (not in my sig) was built in 2009 following the standard build directions in the wiki for the 12-drive server. It has always had periodic and intermittent access issues; most notably when transferring a significant volume of data (several Gb) via SMB running 4.7. I just upgraded it to unRAID 5 yesterday, set up AFP access just like my primary, and set up some significant file transfers last night....and once again, the server dropped out and the file transfer stopped midway. I don't think this is an SMB issue or AFP issue...I think it may be something related to either the particular hardware or perhaps low fault tolerance on the part of unRAID. That is, maybe the older hardware just gets choked down occasionally, and unRAID is unable to manage the server through it so it drops out momentarily. I dunno...not a computer guru, but I'm thinking if a network card or data cable or processor gets bogged down, that's when the drop out occurs. But I can definitely say that AFP, with my primary server, works perfectly. Take care, Phil

Here's what I think I have figured out. When Mac OS X connects to a network server via AFP, it assumes the server handles the resource fork metadata. Netatalk (prior to 3.0) is the culprit for writing the metadata. Netatalk 3.0 (released 9 July) handles these differently. Here's what I don't get: why would Netatalk be writing resource fork stuff while the files are not being accessed? It's like some kind of maintenance drill or something. Hopefully Limetech can upgrade us to Netatalk 3.0 in the near future.

I ran the inotify tool and it found a whole bunch of AppleDouble and AppleDB writes to the drives. Unfortunately I have no clue what that means or how to stop it. The output is attached, if anyone can take a stab. Big thanks to Joe L. for pointing out the utility. Great stuff. inotifyoutput.txt

Really? No one else is having this problem? Drives not spinning down when they should?... I'm. So. Ronereeeeeeee. Phil

I'm running RC-5. I've been having problems with disk spindown on my server. Basically, it has never worked with unRAID 5. I have 8 data drives...here's the breakdown Disk 1 - Single disk share, has data, spindown problems Disk 2 - 1 of 2 disk share, has data, spindown problems Disk 3 - 2 of 2 disk share, no data, spins down as expected Disk 4 - 1 of 2 disk share, has data, spindown problems Disk 5 - 2 of 2 disk share, no data, spins down as expected Disk 6 - Single disk share, no data, spindown problems Disk 7 - Single disk share, no data, spindown problems Disk 8 - Not part of share, no data, spins down as expected I do not have SMB enabled. I use AFP. I have a dedicated Mac Mini server (running Lion Server) and several networked Macs. Spotlight indexing of the unRAID server shares is turned off on all Macs. I'm running a few add-ons, such apcupsd, unMenu, and mail, but nothing that should be accessing disks or shares. The drives are connected to both the motherboard and through sas cards - no correlation there. All drives are set to default spindown (which is 15 minutes). Syslog attached.... Thanks, Phil Update: Changed icon to defect report syslog-2012-07-15.pdf

RC2 installed; no showstoppers. With 5.0b14, I was having an issue that disks would not stay in a spin down condition. Shares were exported via AFP only; disks were exported via SMB only. After RC2 install, I returned to my desired configuration (Shares via AFP, disks via SMB) and the spin down issue has NOT returned as yet. I had thought this was the fault of my Mac computers (NetBios polling SMB drives periodically, causing them to wake), but I guess it was an issue with the previous SMB implementations. Whatever the problem, seems to have been fixed. Still having an issue with spindown under RC2...turned off SMB completely at unRAID server, disks still won't spindown appropriately. Even if I force them to spindown, they spin back up. Curiously, it is only the first drive in every share. For instance, I have two drives in the TV Shows share...only the first one won't spindown. Seems like the issue is with AFP. I run a Mac Mini w/Lion Server in my basement that is 24/7 connected to the drives via AFP. Perhaps there is some kind of periodic refresh query from AFP that goes out to the shares and wakes up the drives? I don't know. Not sure if this is something that can be addressed within unRAID at all, or if I need to alter configurations for my network. It may just be the price I pay (literally, in terms of drive wear and energy usage) for using AFP. AFP is so much easier than SMB - my preference is to stick with it. Should not be a roadblock to a 5.0 final, but something for Limetech to take a look at in a subsequent release. Phil

Just a comparison...I push data from my laptop to my server in the basement via wireless network, and I get 11 Mbps (no cache drive). A wired gigabit connection ought to be screaming. You might make sure everything on your network is configured for gigabit...and make sure all your ethernet cables are Cat 5e or Cat 6 (I prefer Cat 6).

Yeah, as a US Navy officer who has moved his family 17 times in 18 years, I understand how long and what it takes to get settled and start being productive again....although a move from Colorado to California would just be baby steps for me . Hope all is going well. My Beta 5.0 server is humming right along. I have some hardware issues, but they're mine...not Limetech's. My 4.7 server is running perfectly - couldn't ask for better performance. Just can't wait to see what's around the next corner. Maybe I'll buy one of those fancy new servers from Limetech to save me the time and effort of building my own!

I'm running AOC-SASLP-MV8 on B14...Only problem I've had is spin down. Doesn't work properly - as in some do, some don't, and it is only somewhat predictable. As far as the data getting pushed out, etc, no problems at all.

Frank1940, The two seconds after pausing (and spinning down) is your player's buffer running out. Then you have a short pause while the drives spin back up and the movie continues from where the buffer left off. All of what you have identified is normal behavior that I see through AFP or SMB. In short, enjoy unRAID - you don't have a problem.

I disabled all user-installed packages via unmenu, disabled unmenu, rebooted. Ejected the user shares from all computers in the house. Via webgui, I spun down all drives - webgui confirmed all drives were spun down. Spin down command was sent @ 0529 (see attached syslog...I'm in the Navy, early riser...what can I say?). From 0529, I can absolutely confirm there was no user directed or 3rd party software background service write or read access to the server. At 0554, according to the log, a spin down command was sent to drives 2 and 6. As of 0556, the webgui shows drives 2, 3, 5 and 6 as spun down (see attached screenshot) (Never mind, keep exceeding file size limitations for the post - can't make the screenshot clear enough to read). All the computers in my house run Mac OS X Lion, all user shares are exported via AFP only, while disc shares are exported via SMB only. See attached spin down settings file to see user shares/spin down settings by disc. The one thing I cannot confirm is whether or not Lion is accessing the drives to cause the problem; i.e., part of the AFP or SMB background process is accessing drives in order to maintain the connection. I kinda doubt it, because I always have one or two drives that show as spun down. If it is any help, discs 3 and 5 are completely empty (no folders, no files). Disc 6 has only a single folder (no files). There may be something there...it is usually discs 3 and 5 that behave appropriately (spin down). I'm willing to downgrade to 4.7.1 on my server to see if the drives spin down properly under that version. That would eliminate/identify hardware issues. I also have another unRAID server running 4.7.1 beautifully, all drives spin down appropriately (known good configuration), am willing to upgrade it to 5b14 to test spin down as well. Just want to know how much of a one-way trip each of those is: how much configuration/data do I lose going each way? Momma won't tolerate a prolonged absence of our networked media... If there is anything else I need to change in my config to run the tests, let me know and I'll do it. syslog-2011-11-27.txt unRAID_webgui.pdf unRAID_spin_down_settings.txt

Skank - I'm running B14....although the spin down problem has persisted through b12a, b13 and now b14....