Joe L.

Ok... Try this Run the command as shown previously with the "echo" preceeding the handbrake command but capture the output in a file like this: [pre] cp /dev/null /tmp/iso_hb find /mnt/user -name "*.ISO" -print | while read filename do echo converting $filename f=`basename "$filename" .ISO` d=`dirname "$filename"` echo HandBrakeCLI -i "$filename" -t 1 -o "$d/$f.avi" -f avi -p -e ffmpeg -S 700 -a 1 -E lame -B 160 -R 0 -6 dp12 -D 1 -v | tee -a /tmp/iso_hb echo $filename completed done [/pre] When the command runs, you will have a file in /tmp named iso_hb containing all the individual handbrake commands to be run to convert your files. You can then just execute that file of commands with chmod +x /tmp/iso_hb /tmp/iso_hb My best guess is you are running out of memory when running in a loop.

That feature is dependent on your network controller firmware. You are looking for "wake on ARP" You can see what your network card supports by typing ethtool eth0 My server looks like this: ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: umbg Wake-on: g Current message level: 0x00000007 (7) Link detected: yes It cannot be awakened by an ARP request... the network card just does not support it. You are looking for a network card that Supports Wake-on: a <- ARP request.

That is called Wake-On-Lan. You send it a special packet from the apple computer. The network card in the unRAID server will recognize its MAC address and wake the server. Even though the server goes to sleep, it stays powered up. (you'll need to enable Wake-On-Lan in your unRAID MB BIOS too.) Joe L.

I can't tell what you typed from here. It will probably type that handbrake has finished after every iso file. Did you use an editor that did NOT put carriage returns at the ends of lines when you edited the set of commands to change iso to lower case? If not, that might be your issue. Use the "fromdos" command as described in the wiki to fix the script if that is the case. If you type find /mnt/user -name "*.ISO" -print it will print what it would convert. If you add an echo in front of the handbrake command, (in blue below) it will print to the screen the commands it would invoke (instead of invoking them) find /mnt/user -name "*.ISO" -print | while read filename do echo converting $filename f=`basename "$filename" .ISO` d=`dirname "$filename"` echo HandBrakeCLI -i "$filename" -t 1 -o "$d/$f.avi" -f avi -p -e ffmpeg -S 700 -a 1 -E lame -B 160 -R 0 -6 dp12 -D 1 -v echo $filename completed done

Hi Joe L. Would it be an easy and quick excercise for you to help me out on how to modify your script to be recursive on say a hard coded path and always save the converted file in the same folder as the original iso was? Or that would be more difficult task to just quickly draft it down? Thank you! find /mnt/user -name "*.ISO" -print | while read filename do echo converting $filename f=`basename "$filename" .ISO` d=`dirname "$filename"` HandBrakeCLI -i "$filename" -t 1 -o "$d/$f.avi" -f avi -p -e ffmpeg -S 700 -a 1 -E lame -B 160 -R 0 -6 dp12 -D 1 -v echo $filename completed done This will do it for everything under /mnt/user. If you want a different path, change it where I highlighted it in blue above. It specifically looks for files with a capital .ISO suffix. If yours are lower case, change the .ISO to .iso in both places in the script. The output file is the same name as the input, but with a .avi suffix, and it is stored in the same folder as the .ISO Joe L.

I'll bet you can put them on 7 volts instead of 12 to slow them down and still get a lot of air flow, and much less noise. Joe L.

Don't be fooled by your test. Once a "file" is read, it is in the cache until it is replaced by something else needing the cache. To perform your test properly, you'll need to empty the cache between tests. To do that, type this in between each test: sync; echo 3 > /proc/sys/vm/drop_caches

Yes, "tiles" will show you small images of jpg files, and images of documents. It will be examining file content, not just directory data. cache_dirs is not opening every file to read them... Solution, change the view you are using to a file listing mode. Joe L.

As already said, it depends on what you are browsing... If you have thumbnail views enabled, windows is looking at file contents, not just directory listings.

Actually, the ability to add arguments is built in with the "-a" option. An example: cache_dirs -a '-noleaf -name Steam -prune -o -print' Or, if you have more than one directory to exclude: cache_dirs -a '-noleaf \( -name Steam -prune -o -name data -prune \) -o -print' Your example would be cache_dirs -a '-noleaf \( -name "*old" -prune -o -name packages -prune \) -o -print' No need to hack at cache_dirs at all. It was designed to be flexible. When using the -a option you need to use the -noleaf at the beginning of the -a option argument, and -print at the end to get correct syntax. The entire -a option argument is enclosed in single quotes as in -a '-noleaf ....... -print' Individual shell wild-cards "*" can be enclosed in double quotes as in the "*old" example above. Not too difficult... Joe L.

Exactly, it is just that the "find" command accesses all the directories in turn, keeping them from being the least recently used cache blocks available for re-use.

You did not wait until the "long" test was complete... Your report request said: Testing has begun. Please wait 255 minutes for test to complete. Test will complete after Sun May 9 10:05:53 2010 and then, when you requested a status report: Self-test execution status: ( 244) Self-test routine in progress... 40% of test remaining. It is still running... (and if not, it might need to be requested as smartctl -d ata -t long /dev/sdh ) adding the "-d ata" to the command.

yes, even if you have to power cycle or hit reset it will still be happy if it was stopped first. Once you figure out the S3 stuff, you should be able to do it without stopping the array first.

It is correct. The /proc file-system entries are not programs, but a interface to part of the Linux kernel. Think of it as a two way bi-directional port. You can write to it, you can read from it, and a part of the Linux kernel is listening/responding from the other end. /proc/acpi/sleep is supposed to indicate the modes your BIOS indicated it could handle. You might also have to set in your BIOS what it should do when it gets an S3 Sleep request. Some ignore it by default. An FYI, the /proc/acpi/sleep is being replaced by /sys/power/state in newer Linux kernels. See here: http://acpi.sourceforge.net/documentation/sleep.html

The partition is created by the pre-cleared process AND it is part of the pre-clear signature. If you remove it, the disk will not be detected as pre-cleared. You may have run out of RAM running three processes at a time . Depending on what else you were running it might get to fail as it uses pretty large buffer sizes when reading and writing the disks. In any case, it looks like it stalled in the post-read, and that is why the disk appears as pre-cleared. You can accomplish reading the entire disk (to substitute for the post-read that never finished) by running a "long" test via SMART. If it encounters sectors it cannot read it will abort without completing 100%. Type smartctl -t long /dev/sdh Wait the indicated duration, get a new smart report to see the results of the "long" test by typing smartctl -a -d ata /dev/sdh look for sectors pending re-allocation or re-allocated. Look for the "long" test completing 100% One more thing, the error you posted is interesting. The line that failed is this: skip_b=$(( 1+(`head -c4 /dev/urandom| od -An -tu4`)%($blocks) )) It apparently was evaluated as 1+()%(243201) (Note the empty parens "()" where it was expecting a number) That seems to indicate the attempt to get a random number failed when invoking head -c4 /dev/urandom| od -An -tu4 Which brings me back to my original statement, that should never fail unless there is a lack of memory and it was killed when invoked, or it was unable to start. Very interesting indeed. Joe L.

Very nice cabling... How many different length SATA cables did you use?

looks like it is doing exactly what it is supposed to be doing. the "find" command on each of the directories will read into the disk buffer cache the names of the files. Since each "find" is occurring very quickly, I'd guess all the requests are being handles from RAM and not going to the disks at all. In any case, now you know exactly what cache_dirs is doing. You can type find /mnt/disk1/server -noleaf etc, to see the files and folders being read into the disks cache. cache_dirs is throwing away the listings, sending the listing to /dev/null Now, if your "browsing" of the directory is writing to them (MAC OS writes ._DS files) or opening files to show thumbnail views (windows will do this) then yes, the disks will spin up, since the file contents are not cached. Joe L.

Only the directory and file names. And, only if you have enough memory to hold the entire list of directory and file names And, only if they are not displaced by something else needing memory. To see what it is doing, kill the cache_dirs process you have running by typing cache_dirs -q and instead invoke it in the foreground with cache_dirs -F -v Type "Control-C" to exit it when run in the foreground.

It all depends on the UPS. If it has enough capacity to keep the server powered (and asleep) through the outage, then no parity check will occur, since the server really never knew the power dropped. If the initial power-loss signal from the UPS wakes the server up (and I have NO idea if it will wake on USB activity) then I'd guess it might be able to shut the server down. Only some tests would let you know. It is why you perform a "sync" before putting the server to sleep. Hopefully, it will get everything written to the disks that needs writing. Joe L.

Yeah, I noticed that, must be something with windows but my script doesnt have the problem, built it using vi. vi will not add the extra linefeeds. Glad the script is working for you. Windows tries so much to be helpful... and fails so often if the files it is editing are not plain text.

there are at least two places where the attached s3.txt file has had the text wrap onto a second line. Those should be on a single line. You should not use an editor that adds carriage returns or splits long lines adding newlines. Your script will probably fail if it has the same added newlines. Joe L.

speaking of parity check. Using unMenu, will the monthly parity check (tonight 00am), not run if the server is asleep? Or will it run once the server comes back on? I put the server to sleep by clicking the S3 script button in unMenu. It will not run because cron will not invoke it because it will not be running. cron does not go back to run items that were scheduled when it was sleeping. So basically, the monthly check will not run at all. Joe L. thanks Joe, I guess I'll make sure the server is on tonight before going to bed... Sounds like a plan... Worst case, you can press the "Verify Parity" button on the unMENU Array management page in the AM if you forget. Joe L.

speaking of parity check. Using unMenu, will the monthly parity check (tonight 00am), not run if the server is asleep? Or will it run once the server comes back on? I put the server to sleep by clicking the S3 script button in unMenu. It will not run because cron will not invoke it because it will not be running. cron does not go back to run items that were scheduled when it was sleeping. So basically, the monthly check will not run at all. Joe L.

I have no idea... my motherboard does not do S3. If yours does, and if the script does what you need, and it has not exited, it might work. The fact that the nohup.out file is blank simply means there was nothing output from the command as error message or "echo" statements. Joe L. Thanks Joe, cat nohup.out shows nothing. So it's working?

It sounds like your line-endings were wrong and by using notepad2 you fixed them. Type cat nohup.out to see the output of the s3.sh command. (there may not be anything) What you are now seeing now looks normal. Joe L.