interwebtech

this needs to be wiki'd

These are the commands I used to create & map a local share to a remote share on a different unRaid box. Yours may need adjustment depending on what your other server is running. mkdir /mnt/[localShareName] mount -t cifs //[netbios-servername]/[sharename] /mnt/[localShareName] -o username=root@[netbios-servername],password=[remote-tower-root-password],iocharset=utf8,file_mode=0777,dir_mode=0777

Its possible but kind of squirrelly. I was able to connect to another unRAID box to move files. It involved creating a share that mapped to a share on the other box. Let me try and find the discussion...

The 1231 has an Ethernet jack on the back. Plug that into your switch and then in the card's BIOS you will find it's IP# (look around, don't recall exactly where). Open a browser to that IP and you will have the way to update the BIOS. Default login for the web interface is in the card documentation, something like admin:password lol.

Thanks for the suggestions. I have what I need now

oops on the math lol. 200 GB sound better. On both source and destination disk, the same movie folder are inside a top level folder named Movies1. Looking at /mnt/disk3/Movies1/ on the left and /mnt/disk11/Movies1/ I am seeing the same folder name e.g., /127_hours/ at the top of both list and peeking inside each I see that somehow this movie got spanned across the 2 disks. One side holds the video & data files (XML etc) and the other has just the cover image. So I am guessing its safe to move the files from disk3 to disk11 and then just delete the empty dir on disk3?

Back when I consolidated 2 uR servers into one, I didn't leave much slack space on each drive (trying to pack as much as possible at that time). Most are at 99% full. I just upgraded 2 drives to new double capacity drives and want to move some folders to the larger drives to bring all the full drives to @90% full. 2TB drives means I just need to move 1 movie (2 GB) to accomplish that I have 1 huge share named Movies1 than spans all drives in the array. When I opened MC to move 1 or 2 folders to the larger drives off a full disk, I noticed that both sides of MC had the same folder name. Hmmm... that might be a problem. I have read about losing data like this so backed off and came here to ask how to pull this off.

ARC-1230, ARC-1231ML, ARC-1260, ARC-1261ML, ARC-1280, ARC-1280ML bjp999 & bubbaQ have done most of the leg work. Just need it baked into v6 with proper support for drive labels, SMART & drive temps. http://lime-technology.com/forum/index.php?topic=38487

thanks to you and bubbaQ this has turned out to be quite the find and for me at least a substantial performance/capacity upgrade. Thanks again.

[item has been sold] Used Supermicro AOC-SASLP-MV8 for $50. Swapped for an Areca card with more ports. No cables, disks, nothing but the bare card with high profile bracket. Shipped at your expense. PayPal accepted.

Now if we can get drive temps & smart data in the Dynamix WUI this will be a 100% success.

This fixed the autostarting of the array (thanks!). Going to try setting "sleep" to lower value, starting with 5. ps. 5 works fine. Will leave it at that.

spotted this on console before, thought I might mention it: awk: fatal: cannot open file "/var/local/emhttp/smart/disk6" for reading (No such file or directory) repeated for each disk on the Acreca (6-13) and then the whole batch repeated multiple times.

No change. Boots up to "invalid configuration" with drive lables garbled. Running commands via telnet fixes it. Go file: #!/bin/bash # Start the Management Utility cp /boot/60-persistent-storage.rules /lib/udev/rules.d udevadm trigger sleep 30 /usr/local/sbin/emhttp & /boot/unmenu/uu cd /boot/packages && find . -name '*.auto_install' -type f -print | sort | xargs -n1 sh -c

added to go. will test next reboot Thanks for the help. #!/bin/bash # Start the Management Utility cp /boot/60-persistent-storage.rules /lib/udev/rules.d udevadm trigger sleep 5 /usr/local/sbin/emhttp & /boot/unmenu/uu cd /boot/packages && find . -name '*.auto_install' -type f -print | sort | xargs -n1 sh -c sleep 5 had no effect. Had to run commands manually through telnet after reboot.

Not sure if it applies to v6, but when I did similar in v5 I had to load an NTFS driver to be able to read from a SNAP connected USB drive. To be sure, you should wait for a more knowledgeable person to help you.

Curious if you have tried running unRaid off the internal USB3 port. I don't see much sense in this, since unRAID only boots from the flash, and after that runs completely in RAM. I might try it, though, just out of curiosity, during next case opening. Tried it today - unRAID does not boot when flash drive is in USB 3.0 card. Blank screen with blinking cursor. thanks for trying.

added to go. will test next reboot Thanks for the help. #!/bin/bash # Start the Management Utility cp /boot/60-persistent-storage.rules /lib/udev/rules.d udevadm trigger sleep 5 /usr/local/sbin/emhttp & /boot/unmenu/uu cd /boot/packages && find . -name '*.auto_install' -type f -print | sort | xargs -n1 sh -c

This is not something I tested. I just assumed that running those commands any time during the boot process would result in the naming rules being put into practice and used. I do not believe that the rules have anything to do with emhttp or are impacted by the packages that get loaded based on unmenu configuration. But I could be wrong. I am now wondering if the reason moving the commands to the end is making it work is because of the amount of time the other activities is causing sufficient delay for something else the OS is doing in the background to complete. I suggest adding a "sleep 30" (30 second delay) into the go file before running the copy and udevadm trigger commands all before emhttp is loaded. If that doesn't work, add the line "v /dev/disk/by-id >/boot/debug.txt" right after the udevadm trigger command. The output of that command will let you know if the rules change took effect. Ultimately I'd want to know if the rules changed and then were reverted, or if the rules never changed. If you continue to see the rules not taking effect, could you confirm that the updated rules file is, in fact, in the /lib/udev/rules.d directory, or whether the file has been replaced with the original (or some other file) somehow. The command "cp /lib/udev/rules.d/60-persistent-storage.rules /boot/60rules.txt" will put the current file on your flash drive for comparison to bubbaQ's version. I'll also play around on my array this weekend. But since I reboot so infrequently, and I never let the array start on its own, not a big deal for me. Just to be clear the config DOES take effect. Just that the array does not autostart. Like yours, reboots are infrequent here and I can live with needing to manually review & start the array if and when I do. I will try and get this data for you probably into next week as I am replacing two drives this weekend and with data rebuilds and parity checks its going to be occupied for a while.

Going to try adding it at the end? ps. okay now it updates the configuration but the array doesn't start on its own. now current go file #!/bin/bash # Start the Management Utility /usr/local/sbin/emhttp & # cd /boot/packages && find . -name '*.auto_install' -type f -print | sort | xargs -n1 sh -c /boot/unmenu/uu cd /boot/packages && find . -name '*.auto_install' -type f -print | sort | xargs -n1 sh -c cp /boot/60-persistent-storage.rules /lib/udev/rules.d udevadm trigger

firmware all updated, HDD timeout set to 60. Disk config is not surviving reboot. Current go file: #!/bin/bash # Start the Management Utility /usr/local/sbin/emhttp & cp /boot/60-persistent-storage.rules /lib/udev/rules.d udevadm trigger # cd /boot/packages && find . -name '*.auto_install' -type f -print | sort | xargs -n1 sh -c /boot/unmenu/uu cd /boot/packages && find . -name '*.auto_install' -type f -print | sort | xargs -n1 sh -c

Will try putting it on line after emhttp

I loaded the 1.49 BOOT & FIRM bins through the HTTP interface. Do I need to load the other two also (BIOS, MBR0)? I was hesitant since the upload only mentioned the 2 files & once they were loaded System Information inside ARC BIOS showed the new firmware number for both. Is the Spindown in BIOS? I did not change that but will if recommended.

New (to me) ARC-1231ML RAID controller (JBOD mode) with nice performance bump over the AOC-SASLP-MV8 it replaced. Tunables Report from unRAID Tunables Tester v2.2 by Pauven NOTE: Use the smallest set of values that produce good results. Larger values increase server memory use, and may cause stability issues with unRAID, especially if you have any add-ons or plug-ins installed. Test | num_stripes | write_limit | sync_window | Speed --- FULLY AUTOMATIC TEST PASS 1 (Rough - 20 Sample Points @ 3min Duration)--- 1 | 1408 | 768 | 512 | 98.8 MB/s 2 | 1536 | 768 | 640 | 93.9 MB/s 3 | 1664 | 768 | 768 | 75.1 MB/s 4 | 1920 | 896 | 896 | 72.6 MB/s 5 | 2176 | 1024 | 1024 | 73.0 MB/s 6 | 2560 | 1152 | 1152 | 72.9 MB/s 7 | 2816 | 1280 | 1280 | 72.9 MB/s 8 | 3072 | 1408 | 1408 | 74.2 MB/s 9 | 3328 | 1536 | 1536 | 73.3 MB/s 10 | 3584 | 1664 | 1664 | 72.6 MB/s 11 | 3968 | 1792 | 1792 | 73.6 MB/s 12 | 4224 | 1920 | 1920 | 72.6 MB/s 13 | 4480 | 2048 | 2048 | 72.8 MB/s 14 | 4736 | 2176 | 2176 | 71.6 MB/s 15 | 5120 | 2304 | 2304 | 73.0 MB/s 16 | 5376 | 2432 | 2432 | 71.7 MB/s 17 | 5632 | 2560 | 2560 | 73.0 MB/s 18 | 5888 | 2688 | 2688 | 74.3 MB/s 19 | 6144 | 2816 | 2816 | 73.1 MB/s 20 | 6528 | 2944 | 2944 | 71.6 MB/s --- Targeting Fastest Result of md_sync_window 512 bytes for Special Pass --- --- FULLY AUTOMATIC TEST PASS 1b (Rough - 4 Sample Points @ 3min Duration)--- 21 | 896 | 768 | 128 | 57.0 MB/s 22 | 1024 | 768 | 256 | 74.0 MB/s 23 | 1280 | 768 | 384 | 85.5 MB/s 24 | 1408 | 768 | 512 | 90.5 MB/s --- Targeting Fastest Result of md_sync_window 512 bytes for Final Pass --- --- FULLY AUTOMATIC TEST PASS 2 (Final - 16 Sample Points @ 4min Duration)--- 25 | 1288 | 768 | 392 | 86.1 MB/s 26 | 1296 | 768 | 400 | 85.6 MB/s 27 | 1304 | 768 | 408 | 86.6 MB/s 28 | 1312 | 768 | 416 | 87.1 MB/s 29 | 1320 | 768 | 424 | 87.5 MB/s 30 | 1328 | 768 | 432 | 88.3 MB/s 31 | 1336 | 768 | 440 | 88.3 MB/s 32 | 1344 | 768 | 448 | 88.6 MB/s 33 | 1360 | 768 | 456 | 88.8 MB/s 34 | 1368 | 768 | 464 | 89.2 MB/s 35 | 1376 | 768 | 472 | 89.4 MB/s 36 | 1384 | 768 | 480 | 89.4 MB/s 37 | 1392 | 768 | 488 | 90.2 MB/s 38 | 1400 | 768 | 496 | 89.9 MB/s 39 | 1408 | 768 | 504 | 90.7 MB/s 40 | 1416 | 768 | 512 | 90.9 MB/s Completed: 2 Hrs 24 Min 48 Sec. Best Bang for the Buck: Test 1 with a speed of 98.8 MB/s Tunable (md_num_stripes): 1408 Tunable (md_write_limit): 768 Tunable (md_sync_window): 512 These settings will consume 71MB of RAM on your hardware. Unthrottled values for your server came from Test 40 with a speed of 90.9 MB/s Tunable (md_num_stripes): 1416 Tunable (md_write_limit): 768 Tunable (md_sync_window): 512 These settings will consume 71MB of RAM on your hardware. This is -7MB less than your current utilization of 78MB. NOTE: Adding additional drives will increase memory consumption. In unRAID, go to Settings > Disk Settings to set your chosen parameter values.

FYI I am getting a nice speed boost from ARC-1231ML over the AOC-SASLP-MV8 it replaced. Ran unraid-tunables-tester.sh in full auto and the speeds show about 67% improvement AND using -7MB less RAM. I am a happy customer. current run on ARC-1231ML Completed: 2 Hrs 24 Min 48 Sec. Best Bang for the Buck: Test 1 with a speed of 98.8 MB/s Tunable (md_num_stripes): 1408 Tunable (md_write_limit): 768 Tunable (md_sync_window): 512 These settings will consume 71MB of RAM on your hardware. Unthrottled values for your server came from Test 40 with a speed of 90.9 MB/s Tunable (md_num_stripes): 1416 Tunable (md_write_limit): 768 Tunable (md_sync_window): 512 These settings will consume 71MB of RAM on your hardware. This is -7MB less than your current utilization of 78MB. NOTE: Adding additional drives will increase memory consumption previous results on the AOC-SASLP-MV8... Completed: 2 Hrs 14 Min 4 Sec. Best Bang for the Buck: Test 2 with a speed of 66.6 MB/s Tunable (md_num_stripes): 1536 Tunable (md_write_limit): 768 Tunable (md_sync_window): 640 These settings will consume 78MB of RAM on your hardware. Unthrottled values for your server came from Test 23 with a speed of 69.3 MB/s Tunable (md_num_stripes): 6024 Tunable (md_write_limit): 2712 Tunable (md_sync_window): 2712 These settings will consume 305MB of RAM on your hardware. This is 240MB more than your current utilization of 65MB. NOTE: Adding additional drives will increase memory consumption.