mikejp

I used the promo code that I received from NewEgg in one of thier e-mail fliers... happens to be the same code posted above. Called customer service & they made it right... She said it was a valid promo & applied it to my order. Gotta love NewEgg customer service ;D

Just tried to order one using the listed promo code... "Sorry, the promo code HARDOCP1X19A you've entered is invalid." is what I got...

Tiger Direct still have 3tb Hitachis for $139 + shipping... cheapest I've found so far. http://www.tigerdirect.com/applications/SearchTools/item-details.asp?EdpNo=149703&CatId=4357 Glad I'm not in need at the moment... :-\

The HITACHI Deskstar 5K3000 HDS5C3030ALA630 went up $50 since this morning on NewEgg!! $70 since Monday...:'( :'( http://www.newegg.com/Product/Product.aspx?Item=N82E16822145561

How does he turn off debugging? Settings page--> Notifications--> SMTP Configuration--> The first setting is Debug.. yes or no.

Which one?

"I'd love to sell it locally (NYC) but could ship it, too."... quote from the OP. That being said... any idea on dimensions & weight? I'd be interested in it for a backup , if the shipping isn't too much.

Wondering the same thing a while back & found this from Tom in an old post: None of these tunables have anything to do with the Cache Drive; they are 'tweaks' for the low-level unraid array driver only. First, you can create a file in the 'config' directory of the Flash called 'extra.cfg'. This file is read when the array is Started and may be used to define the values (or override default values) of these tunables. Here are the current defaults: md_num_stripes=1280 md_write_limit=768 md_sync_window=288 md_num_stripes defines the maximum number of active 'stripes' the driver can maintain. You can think of a 'stripe' as a 4K I/O request. For example, let's say you are reading a large (many megabytes) file from the server. Well the driver will "see" a series of (largely) sequential 4K read requests. The driver will determine which disk the read is for and then pass that 4K read request to the disk driver. Well the most such requests would be 1280. If there are 1280 requests already active and another request comes in, then the process making that request has to wait until a stripe become free (as a result of previous I/O finishing). Bottom line is this: the greater this number is, the more I/O can be queued down into the disk drives. However each 'stripe' requires memory in the amount of (4096 x highest disk number in array). So if you have 20 disks, each stripe will require 81920 bytes of memory; multiplied by 1280 = over 104MB. The default value was chosen to maximize performance in systems with only 512MB of RAM. If you have more RAM then you can experiment with higher values. If you go too high and the system starts running out of memory, what will happen is 'random' processes will start getting killed (not good). md_write_limit specifies the maximum number of stripes which will be used for write. This is because if you starting writing a large file, there can easily be 'md_num_stripes' requests immediately queued. This will cause reads to different disks to suffer greatly. So you want to pick a number here that is large but which also leaves some stripes available for reads. You will find there is a point of diminishing returns. If you set the number low, say 32, then writes will be very slow. If you leave it at default, writes will be much faster. If you set it to say 1000, writes will be a "little bit" faster. By increasing both md_num_stripes and md_write_limit you might get 10% more performance than default values. The best you can get is going to be something less than 50% the raw speed of the disk - if you get above 33% let me know md_sync_window specifies the most number of parity-sync stripes active during a parity-sync or parity-check operation. Again, the larger this number, the faster parity-sync will run, with diminishing returns at some point (due mainly to saturating PCI and/or PCIe buses). You want to make sure the sum of md_write_limit+md_sync_window < md_num_stripes so that reads do not get starved if you starting writing a large file while a parity-sync/check is in process. Hopefully I will be able to write up a more thorough document on this subject along with some of theory behind it. Note: if you change the values of these tunables via the 'extra.cfg' file, you must Stop the array, then Start the array for the values to take effect. The md_write_limit and md_sync_window may be dynamically changed by typing these commands in a telnet session: mdcmd set md_write_limit <value> mdcmd set md_sync_window <value>

page allocation failure's typically indicate you've run out of memory. Thanks for the response JoeL... I've been playing around with the "Tunables" on the Disk Settings page... probably got over zealous with my "tuning" With 8GB of ram, I didn't think I would run into a memory shortage. Are there any "magic numbers" that help here? Thanks again

Good Morning, I got up this morning & checked my server, as I started a parity check before bed. I discovered the following error repeating itself at the end of my syslog: Sep 11 21:31:10 Tower2 kernel: kworker/0:1: page allocation failure: order:4, mode:0x4020 Sep 11 21:31:10 Tower2 kernel: Pid: 0, comm: kworker/0:1 Not tainted 3.0.3-unRAID #7 Sep 11 21:31:10 Tower2 kernel: Call Trace: Sep 11 21:31:10 Tower2 kernel: [<c105f857>] warn_alloc_failed+0xb2/0xc4 Sep 11 21:31:10 Tower2 kernel: [<c105ffc2>] __alloc_pages_nodemask+0x456/0x47f Sep 11 21:31:10 Tower2 kernel: [<c106003f>] __get_free_pages+0xf/0x21 Sep 11 21:31:10 Tower2 kernel: [<c107d6cd>] __kmalloc+0x28/0xff Sep 11 21:31:10 Tower2 kernel: [<c128e974>] pskb_expand_head+0xcb/0x1f0 Sep 11 21:31:10 Tower2 kernel: [<c128ee08>] __pskb_pull_tail+0x41/0x21f Sep 11 21:31:10 Tower2 kernel: [<c1295b6c>] dev_hard_start_xmit+0x204/0x31c Sep 11 21:31:10 Tower2 kernel: [<c12a4466>] sch_direct_xmit+0x50/0x137 Sep 11 21:31:10 Tower2 kernel: [<c1295d82>] dev_queue_xmit+0xfe/0x274 Sep 11 21:31:10 Tower2 kernel: [<c12b0127>] ip_finish_output+0x227/0x262 Sep 11 21:31:10 Tower2 kernel: [<c12b01c6>] ip_output+0x64/0x68 Sep 11 21:31:10 Tower2 kernel: [<c12adf4d>] ip_local_out+0x57/0x5b Sep 11 21:31:10 Tower2 kernel: [<c12afb5a>] ip_queue_xmit+0x2a5/0x2f2 Sep 11 21:31:10 Tower2 kernel: [<c12beee8>] tcp_transmit_skb+0x4d7/0x50d Sep 11 21:31:10 Tower2 kernel: [<c12c11f7>] tcp_write_xmit+0x2f9/0x3d7 Sep 11 21:31:10 Tower2 kernel: [<c12c1319>] __tcp_push_pending_frames+0x18/0x6f Sep 11 21:31:10 Tower2 kernel: [<c12bdfc9>] tcp_rcv_established+0x501/0x578 Sep 11 21:31:10 Tower2 kernel: [<c12c33b5>] tcp_v4_do_rcv+0x46/0x137 Sep 11 21:31:10 Tower2 kernel: [<c12c386c>] tcp_v4_rcv+0x3c6/0x647 Sep 11 21:31:10 Tower2 kernel: [<c12ac081>] ip_local_deliver_finish+0x93/0x158 Sep 11 21:31:10 Tower2 kernel: [<c12ac172>] ip_local_deliver+0x2c/0x2f Sep 11 21:31:10 Tower2 kernel: [<c12abd8b>] ip_rcv_finish+0x263/0x28b Sep 11 21:31:10 Tower2 kernel: [<c12abfbb>] ip_rcv+0x208/0x23b Sep 11 21:31:10 Tower2 kernel: [<c1293604>] __netif_receive_skb+0x234/0x25a Sep 11 21:31:10 Tower2 kernel: [<c1294a5f>] netif_receive_skb+0x5d/0x63 Sep 11 21:31:10 Tower2 kernel: [<c1294b1c>] napi_skb_finish+0x1e/0x34 Sep 11 21:31:10 Tower2 kernel: [<c1294f4c>] napi_gro_receive+0xc7/0xcf Sep 11 21:31:10 Tower2 kernel: [<c128f0ee>] ? __alloc_skb+0x53/0xf1 Sep 11 21:31:10 Tower2 kernel: [<f84d5651>] e1000_receive_skb+0x36/0x3b [e1000] Sep 11 21:31:10 Tower2 kernel: [<f84d5d79>] e1000_clean_rx_irq+0x291/0x32c [e1000] Sep 11 21:31:10 Tower2 kernel: [<f84d8926>] e1000_clean+0x3c/0x18f [e1000] Sep 11 21:31:10 Tower2 kernel: [<c1295022>] net_rx_action+0x59/0x12a Sep 11 21:31:10 Tower2 kernel: [<c102ccce>] __do_softirq+0x6b/0xe5 Sep 11 21:31:10 Tower2 kernel: [<c102cc63>] ? irq_enter+0x3c/0x3c Sep 11 21:31:10 Tower2 kernel: <IRQ> [<c102cb21>] ? irq_exit+0x32/0x53 Sep 11 21:31:10 Tower2 kernel: [<c100360b>] ? do_IRQ+0x7c/0x90 Sep 11 21:31:10 Tower2 kernel: [<c130b8a9>] ? common_interrupt+0x29/0x30 Sep 11 21:31:10 Tower2 kernel: [<c1007e14>] ? default_idle+0x2e/0x43 Sep 11 21:31:10 Tower2 kernel: [<c1001a60>] ? cpu_idle+0x3a/0x52 Sep 11 21:31:10 Tower2 kernel: [<c1306753>] ? start_secondary+0xad/0xaf Sep 11 21:31:10 Tower2 kernel: Mem-Info: Sep 11 21:31:10 Tower2 kernel: DMA per-cpu: Sep 11 21:31:10 Tower2 kernel: CPU 0: hi: 0, btch: 1 usd: 0 Sep 11 21:31:10 Tower2 kernel: CPU 1: hi: 0, btch: 1 usd: 0 Sep 11 21:31:10 Tower2 kernel: CPU 2: hi: 0, btch: 1 usd: 0 Sep 11 21:31:10 Tower2 kernel: Normal per-cpu: Sep 11 21:31:10 Tower2 kernel: CPU 0: hi: 186, btch: 31 usd: 23 Sep 11 21:31:10 Tower2 kernel: CPU 1: hi: 186, btch: 31 usd: 177 Sep 11 21:31:10 Tower2 kernel: CPU 2: hi: 186, btch: 31 usd: 154 Sep 11 21:31:10 Tower2 kernel: HighMem per-cpu: Sep 11 21:31:10 Tower2 kernel: CPU 0: hi: 186, btch: 31 usd: 121 Sep 11 21:31:10 Tower2 kernel: CPU 1: hi: 186, btch: 31 usd: 133 Sep 11 21:31:10 Tower2 kernel: CPU 2: hi: 186, btch: 31 usd: 146 Sep 11 21:31:10 Tower2 kernel: active_anon:3358 inactive_anon:41 isolated_anon:0 Sep 11 21:31:10 Tower2 kernel: active_file:63400 inactive_file:1029066 isolated_file:0 Sep 11 21:31:10 Tower2 kernel: unevictable:49651 dirty:0 writeback:0 unstable:0 Sep 11 21:31:10 Tower2 kernel: free:850106 slab_reclaimable:27057 slab_unreclaimable:4848 Sep 11 21:31:10 Tower2 kernel: mapped:2150 shmem:62 pagetables:158 bounce:0 Sep 11 21:31:10 Tower2 kernel: DMA free:3692kB min:64kB low:80kB high:96kB active_anon:0kB inactive_anon:0kB active_file:2316kB inactive_file:2484kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15776kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:4364kB slab_unreclaimable:3016kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no Sep 11 21:31:10 Tower2 kernel: lowmem_reserve[]: 0 869 8104 8104 Sep 11 21:31:10 Tower2 kernel: Normal free:78328kB min:3736kB low:4668kB high:5604kB active_anon:0kB inactive_anon:0kB active_file:220896kB inactive_file:220976kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:890008kB mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:0kB slab_reclaimable:103864kB slab_unreclaimable:16376kB kernel_stack:784kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no Sep 11 21:31:10 Tower2 kernel: lowmem_reserve[]: 0 0 57884 57884 Sep 11 21:31:10 Tower2 kernel: HighMem free:3318404kB min:512kB low:8288kB high:16068kB active_anon:13432kB inactive_anon:164kB active_file:30388kB inactive_file:3892804kB unevictable:198604kB isolated(anon):0kB isolated(file):0kB present:7409192kB mlocked:0kB dirty:0kB writeback:0kB mapped:8596kB shmem:248kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:632kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no Sep 11 21:31:10 Tower2 kernel: lowmem_reserve[]: 0 0 0 0 Sep 11 21:31:10 Tower2 kernel: DMA: 173*4kB 131*8kB 68*16kB 27*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 3692kB Sep 11 21:31:10 Tower2 kernel: Normal: 10172*4kB 4562*8kB 70*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 78304kB Sep 11 21:31:10 Tower2 kernel: HighMem: 14893*4kB 104434*8kB 76666*16kB 30467*32kB 3245*64kB 68*128kB 1*256kB 0*512kB 1*1024kB 0*2048kB 1*4096kB = 3318404kB Sep 11 21:31:10 Tower2 kernel: 1142214 total pagecache pages Sep 11 21:31:10 Tower2 kernel: 0 pages in swap cache Sep 11 21:31:10 Tower2 kernel: Swap cache stats: add 0, delete 0, find 0/0 Sep 11 21:31:10 Tower2 kernel: Free swap = 0kB Sep 11 21:31:10 Tower2 kernel: Total swap = 0kB Sep 11 21:31:10 Tower2 kernel: 2228208 pages RAM Sep 11 21:31:10 Tower2 kernel: 1999874 pages HighMem Sep 11 21:31:10 Tower2 kernel: 150938 pages reserved Sep 11 21:31:10 Tower2 kernel: 1017284 pages shared Sep 11 21:31:10 Tower2 kernel: 211216 pages non-shared Sep 11 21:31:32 Tower2 kernel: kworker/0:1: page allocation failure: order:4, mode:0x4020 Would someone please look over the attached syslog, & maybe give me a clue as to what happened & how to fix it?? Thanks... syslog-2011-09-12.zip

???

I can't find it now either... it was listed on the main page under "Featured Deals" "Price Drop" Guess I should have snagged one when i found it... :'(

http://www.mwave.com/mwave/SKUSearch.asp?px=MK&scriteria=76981AA

+1 After having various power related problems with various builds over the years --- including both my unRaid servers, using power supplies from Corsair, Antec, Rosewill, etc., I started using SeaSonic X-Series Gold power supplies only. They are more expensive, (go on sale regularly though) but in my opinion---worth it!! I have had no power related issues with any of my 'puters since! Just my 2 cents worth --- YMMV

Utils tab Vars Scroll down to near the bottom to: [var] => Array [flashGUID] => xxxxxxxxxxxxxxxxxxxx

Tophicles I can understand your frustration here. even I had to struggle a lot to get my user share work exactly the way I wanted to. But public was the least of my concern. It was with Secure and Private along with stupid windows "password management features" that made the whole thing complex. With permission set to public, I am able to access all my files on all shares, with what ever login user..... I log in to my PCs in my lan. What is the message you get when you try to access shares which are set to public. Also make sure you have the same workgroup across all PCs including your Unraid. All of my PCs (including 3 macs) are in the same workgroup. I have the shares set to "Public" but when I try to rename, cut or move a file it tells me: PC: You do not have permission to perform this action. MAC: You need permission from 'nobody' in order to perform this action. On some files and folders though, this works fine... it's almost a random thing. I was having kind of the same problem... I could access everything on my server(using win7) except my TV SHOWS share. I could access the drives containing the folders... but not the folders containing the shows. I tried numerous times running the New Permission script on the Utilities page. When I tried accessing the share a few hours later, I was always greeted by the "no permission thing". I finally ran the New Permissions script on the 2 drives from the console... Probably not the right way to do things... but it worked for me

"This process can take a long time if you have many files." So... how long could/should a "long time" be?

Not on Kodachrome? PATA drive? It's your build... & not mine

What I've done & it seems to work fine is: Stop the array Remove the drive Insert the new drive Refresh the web page The new drive shows available Assign the new drive Restart the array Hope that helps accomplish what you want... Mike

Have you tried going into the settings for each disk, setting a value other then default, hit apply, and see of that works? Shawn I went into the settings for each disk, didn't change anything, hit apply, hit done... drives spin down as they should. Mike

Just a quick Thank You!!! to madburg for the slick M1015 flash package. I used this on a card last night and it worked perfectly, it really can't get much simpler. Please keep up the great work! Add me to the list THANK YOU madburg!! I just flashed 2 M1015s with no problems. The package makes it so simple... even I can do it Thanks again... SBRM1015.zip

I determined my layout pretty much the same way as Johnm. Attached is a copy of MySlots, from unMenu, for the layout of my 4220. Also, a capture of the main web page. Good Luck

I let all the pre-clears finish, rebooted the server, everything works as it should. Thanks again!

Thanks for looking Joe, really appreciate it!! Tower2 login: root Linux 2.6.39.3-unRAID. root@Tower2:~# free total used free shared buffers cached Mem: 4148280 4052228 96052 0 751652 3119760 -/+ buffers/cache: 180816 3967464 Swap: 0 0 0 root@Tower2:~# Since my last post I've stopped the 2 instances that were running 2.6 MB/s using ctrl-c. Thanks

An updated syslog since the last... There is something wrong somewhere! syslog2.zip