schmegg

http://www.newegg.com/Product/Product.aspx?Item=N82E16822136874 Use coupon code GAHDDTEN for $11.00 off the $109.99 base price.

good point, it would probably be burdensome to maintain a really detailed, evolving list of "what works" with unRAID. i guess instead of having specific brands/models such a guideline would have to be broad enough to cover a family of devices/products (eg, only Intel chipset NICs will be 'guaranteed' to work) my larger concern is with current unRAID users who might would be be opposed to a hardware standard for future releases. my guess is most current license holders would be okay with it. say for example, version 6 of unRAID was to be 64-bit only (people can go on using older 32-bit versions all they wanted, but Tom would only need to 'support' the 64-bit version in his coding/testing/development. from where i stand, it's like this: Option A: Get a new software release from Tom, wait for the unRAID 'power users' with non-prod systems to test it, provide feedback on the forums, wait for LimeTech to come up with a coding solution, code it, test it, release it, and then repeat the entire process again. Option B: i got out and buy/borrow/trade a $19 NIC that is known to work perfectly fine (because it matches the hardware LimeTech recommends/uses for their testing) am i oversimplifying it?

i wholeheartedly agree with his statement. i dont want hardware compatibility fixes to stifle development so much that it hinders unRAID's viability as a lifelong storage solution for me. i'm talking about unRAID - the software product, NOT an unRAID System (the collective hardware and OS you assembled at home). software companies place constraints on end users all the time and they routinely retire support for older hardware systems. personally i dont mind being "locked in" to a particular set of hardware compatibility guidelines, AS LONG AS those guidelines are well defined *before* i purchase a license. if anyone wants to talk more about it, i started a separate thread here: http://lime-technology.com/forum/index.php?topic=25692.0

relevant "5.0 final" announcements thread here: http://lime-technology.com/forum/index.php?topic=25611.0 in the thread linked above, Tom mentioned some new cool features for future versions of 64-bit unRAID which could potentially be really awesome. several have already brought up that changes which are exclusive to a 64-bit hardware could hurt a lot of current unRAID users since they still have 32-bit rigs. now, based on what I've seen in the forums, it appears that the "slow-write" problem (holding back 5.0 final) as well as the infamous Realtek NIC issue have been significant hindrances (among others) to a speedy release of version 5. with all this in mind, i'd like to hear the community's your thoughts on these questions: what if there were stricter hardware requirements for future versions of unRAID? if it led to faster development or better 'official' support, to what extent would it be an acceptable change for you? what types of hardware do you consider reasonable to compromise on (or not at all)? i wholeheartedly agree with jaybee's statement. i dont want hardware compatibility fixes to stifle development so much that it hinders unRAID's viability as a lifelong storage solution for me. i'm talking about unRAID - the software product, NOT an unRAID System (the collective hardware and OS you assembled at home). software companies place constraints on end users all the time and they routinely retire support for older hardware systems. personally i dont really mind being "locked in" to a particular set of hardware compatibility guidelines, as long as those guidelines are defined *before* i purchase a license and they dont dramatically alter the usability of the software for me. those who are unwilling/unable to meet hardware compatibility requirements for future releases (like 64 bit or Intel-only NICs) lose nothing except the ability to enjoy future-version-exclusive-features. the fact that these new features are all completely FREE and that Tom doesn't charge for new versions goes a long way in my book. it's not like i'm paying for a subscription/service. unRAID has added so much security, stability, and enjoyment to my life that i would gladly give up the luxury of using a particular NIC (or processor series or mobo or SATA chipset) in order to continue reaping the benefits of such great software. not everyone will agree with this - just my opinion. what are your thoughts?

amazing deal, thanks for sharing!

alright, here goes..... (presses Start button) WHEW! that's a relief, it's now recalculating parity, all my data is intact! thanks a ton Joe L., you're a freakin unraid rockstar. and thanks to Limetech for such a damn fine piece of software

okay, so i deleted the super.dat file from the flash drive then rebooted the server. when it starts up I see the following in the webUI: and in myMain (via unMenu): I confirmed (using a screenshot i took a few weeks ago) that the drive assignments shown are correct, including the cache drive. So now I should press Start on the main page? i am just a little sketchy since the config seems to think all these disks are new, i worry that it will then ask me to Format the drives, which I know I do not want.

i have had a rock-solid 5.0beta2 server up and running the couple months and early this morning i ran into a problem. after rebooting my server the tower web interface showed up with blue dots next to every drive in the array (except cahce drive). syslog indicates that super.dat file is not accessible i powered down the system and put the USB drive into my other pc so i could attempt to backup any config/scripts (just in case). when i did this, windows 7 prompted me to scan and fix the drive - it basically said the file super.dat was corrupted and attempted to recover it (it put the recovered fragments file into FOUND dir on flash drive). now, if i try to start up the server, the system always freezes during bootup and i cannot access using terminal or webUI (or anything). i have considered this might be a hardware failure..... but assuming it is just a problem with super.dat, how do i make unraid happy again? can i just delete the corrupt super.dat file and try rebooting without it?

in order to make the files sabnzbd has downloaded have the file permissions i wanted, i just made a script: it just checks to see if such a directory exists then changes the permission on each folder (and its contents). the folder names are based on how my Categories are set up to download in sabnzbd. you will need to modify the script to suit your own categories/folders. you also need to specify the username:group since you wont have the same group "pwusers" on your system. or just remove the lines that have "chown" in it and change the lines with "chmod -R 775" to say "chmod -R 777" (this will make all the files accessible to anyone, no security basically). copy the script (after you modified it) onto your flash drive (eg, /flash/scripts/chownchmod.sh). to make this automatic, I just added a line to crontab to run the script, chownchmod.sh, every 5 minutes. if you dont know how to do this, here is an outline of the steps: - at the command prompt, type "crontab -e" - use the commands shown here http://www.computerhope.com/unix/uvi.htm#05 to edit the file. google "linux VI editor" for more help on this - the line you add will look something like this: */5 * * * * /boot/scripts/chownchmod.sh >/dev/null 2>&1 - when you are finished, press "SHIFT+q" then type "qw" to save changes its not an elegant solution but it gets the job done. helpful links: http://www.funtoo.org/en/articles/linux/lpi/3/ search for "chown" to find the relevant part http://www.openjs.com/scripts/jslibrary/demos/crontab.php

just curious Rajahal, how long did the zeroing process take you (using the 2048 block size)?

this made me laugh. you really nailed it based on my experiences (currently at the True Believer stage)

easy enough. thanks for confirming.

Earlier this week I set up an experimental 5.0-beta2 server (after many many hours reading through helpful forums threads). I have experimented with it quite a lot and feel I know a little about unraid now but I'm still new to this so I apolagize in advance if what I am reporting is normal. On 2 separate occasions with different sets of hardware I've been able to create a new array without performing the "clearing" step. the first time was using 3 1.5TB drives on my "primary server". the second was using a spare system I had laying around. Here is what I did the second time: - format and load up flash drive using unraid 5.0-beta2 basic - connect HDDs (2 drives, 500GB for parity 320GB data disk) - boot off USB - go to the webgui > Settings > Disk devices - assign the drives then click Done - go to Main page and Start the array - after a few seconds, I refresh the page then I click Format to begin formatting the 320GB drive (all the while, the parity sync appears to be already running in the background) - the parity drive shows an orange ball next to it, the data drives shows green. the readout says "Formatting" on the line corresponding to the data disk - after < 5 minutes, I can refresh the page and the data disk shows up as "Formatted". done. finished. i can transfer data to the array (it is still running the parity sync though) Isn't the clearing step (writing all zeros to the drive) supposed to take a long time? I looked in the syslog and there appears to be some issue with mounting the file system. see attached. the drives I am using have NOT been precleared using the preclear_disk.sh script and these drives were both completely full of data (parts from a win7 NTFS RAID server I recently dismantled) just before I began so I know they have not been cleared. please note: I only observed this with the Basic edition. yesterday I purchased a Pro license and when I added a disk to an already created array in Pro, the drive took 10+ hours to format/clear (as I would expect). Is the purpose of clearing the drives strictly for preserving parity? if so, I guess it makes sense the drives in the newly created array (prior to finishing parity check) should bypass the clearing, right? I just want to make sure my array is set up properly before transferring all my data to it. syslog.txt

take forever to preclear that big SOB