Joe L.

Other things to check... Is the file executable type ls -l /boot/custom/bin if not, Type chmod +x /boot/custom/s3.sh If you edited s3.sh, did you accidentally add non unix style line endings? See this entry in the wiki: http://lime-technology.com/wiki/index.php?title=FAQ#Why_do_my_scripts_have_problems_with_end-of-lines.3F

Hi there, I'm having the same problem as you, nohup s3.sh and it says there's no such file/directory. I didn't edit the script, I just moved it into the custom/bin directory, renamed it s3.sh, chmod-ed it. But somehow it doesn't work. What am I missing? It is probably not in your search PATH. Try giving it a full path nohup /boot/custom/bin/s3.sh & or a "change directory" and give a relative path of ./s3.sh" cd /boot/custom/bin nohup ./s3.sh &

Good idea.

It is not inrush current, although I'd be willing to bet it is even higher than the "peak" values mentioned by the manufacturers, but it is the extra current needed to get the disks to spin up to their rated RPM. It is much more than a fraction of a second, but instead the entire time the disks are accelerating. For some disks, this could easily be 10 seconds or more. In fact, some "green" drive boast about how slowly they spin up to speed. (Actually, they boast about how they've reduced their peak power needs when spinning up, by using a smaller motor, and taking a longer time to slowly spin up to speed) You might be able to have the disk controllers stagger the disk spinup on boot-up, by when you do a parity calc, or when you have a disk fail and all the others have to spin up at the same time it does not work. Basically, even if you have a power supply capable of unlimited current, if there are wires or connector contacts with any fraction of an ohm resistance between it and the disks it powers you have significant voltage drops once the currents increase. I left out a few voltage drops in my past example... Again assume a perfect 12 volt supply 12 Volts starting voltage. 40 Amps of current through 1 foot of 16 gauge wire = 0.1892 volts 40 Amps of current through 20 milliohm molex connector = .8 volts 40 Amps through a parallel pair of 20 miliohm molex pins (the two ground pins) = .4 volts 40 Amps through 1 foot of a parallel pair of 16 guage wires (the two ground wires back to the power supply) = .2 volts 12 volts minus .1892 volts - .8 volts - .4 volts - .2 volts = 10.41 volts at the hard disk. (In my prior post I did not account for the voltage drop of the ground wires going back to the power supply) And it does not matter how good your power supply might be. If the supply is unable to keep up with the current demand, it is even worse. If it drops a few tenths of a volt under load, then combined with the resistance of the wiring, the end result might be out of tolerance for a disk. Wiring harness resistance is why even a 750 Watt supply may not be able to handle large numbers of drives. As much as you might like a single connection to the power supply, you can't cheat physics (not until we get room-temperature superconducting power harnesses). Joe L.

Uhm, no. then please define how the amperage load is divided between the 4 connectors. i have no issues running 12/16 hdds off a single line off my psu with sata cli pon connectors i assume psu modular connectors pins are very much identical to the pins used in a molex 4 pin connector. Color Type Pin 1 Yellow +12 V Pin 2 Black Ground Pin 3 Black Ground Pin 4 Red +5 V We've not talked much about the 5 Volt current needed by disks because the 5Volt lines on power supplies are much higher amperage than the 12 volt supplies. According to the site quoted earlier the 5 volt wattage ranged from 2 watts to 4 watts. (.4 to .8 Amps per disk.) 20 disks therefore will use an average of 12 Amperes of current on the pin 4, the 5 Volt connection. Pin 1, the 12 Volt connection will have 40 Amps through it on spin-up. The two other pins, pin 2 and 3 share the return current (Korchoff's Law), as they are in parallel. They then share evenly 52 Amperes of current (26 Amperes of current each) Therefore Pin 1 = 40 Amperes Pin 2 = 26 Amperes Pin 3 = 26 Amperes Pin 4 = 12 Amperes So, in the case of 20 drives, all spinning up, all through 1 connector, the only pin even close to its rating is pin 4. Basically, all are being used over their rated current capacity. Now for the bad news. Every connection has some resistance. when you pass current through a resistance you have a voltage drop. Looking up the expected "resistance" of a molex connector I find it listed as 20 miliohms. Plugging this into google and it says: (40 amperes) * 20 milliohms = 0.8 volts This means our 12 volt line is now 11.2 volts, and actually, changing as the current draw changes while the drives spin up. Worse than that, 40 Amperes * .8 Volts = 32 Watts. Our poor connector pin will be dissipating 32 Watts of heat. (The connector will be getting warm) Oh, but wait... That is just the one pin. The other pins also have their voltage drops. Pin 2 = (20 milliohms) * 26 amperes = 0.52 volts drop (13.52 Watts heat) Pin 3 = (20 milliohms) * 26 amperes = 0.52 volts drop (13.52 Watts heat) Pin 4 = (20 milliohms) * 12 amperes = 0.24 volts drop (2.88 Watts heat) The total heat is 61.92 Watts. Ouch... ever grab hold of a 60 Watt light bulb... pretty hot isn't it. I'm thinking it is a good thing the spinup time is only 30 seconds or so, but even when not spinning up, we are over the ratings of single pins in the connector. The wire from the power supply to the connector probably is pretty heavy gauge, let's guess it is 16 gauge. Let's guess there are two feet of wire involved(one foot from the supply to the disk, one foot of wire for the ground return). The resistance of 16 gauge wire is .00473 ohms per foot. Doing the math, two feet of wire, carrying 40 Amperes will have (.00473 * 2) * 40 = 0.3784 Volts drop across it. In reality, the wire distance to the disk from the supply is frequently much more than 1 foot. Now, subtracting that from 11.2 and we see the disk is actually getting 10.82 Volts when everything is spinning up. Still sound good to you? Remember, earlier I posted a note from a disk spec sheet describing how disks were very sensitive to voltage variations (noise) greater than .1 volts and if being read or written while the voltage is changing, the results were not guaranteed. I don't have a degree in Math, but my grade school math skills are enough to tell me that 1.17 volts of noise is likely to cause issues. Is it no wonder why disks become unstable when too many are attached to a power supply through a single connector, or even multiple connectors through a single cable, even if the power supply is able to supply the rated current. Joe L.

Does not matter about the wire guage (well, it does if it is too small). Instead, we are talking about the single molex connector feeding all 20 drives. It apparently is rated for 11 Amps based on the size of its connecting surfaces. It will be stressed at a 40 Amp load starting to spin 20 drives.

Thanks... I'll see if I can figure out what is the root cause.

hello, has this been confirmed ... can you possibly run 20 drives only connecting one molex for each backplane ? has anyone done this ? thanks in advance 20 drives, each pulling 2 amps upon spin-up will in total draw 40 Amps of current. A single molex is not rated for that amount of current. It might work, but you are going to be asking for trouble. There is a reason the ATX spec limited any single rail to 18 Amps. According to this page, the molex connector is rated for 11 Amps.

Only "Top level" directories can be excluded using the -e option. I never wrote it to be able to exclude directories further down the hierarchy. Use -e "Other Files" or you can edit the program at around line 372 is this: dir_list=`build_dir_list` change it to dir_list=`build_dir_list | grep -v "Steam"` and then you don't need to use any -e options, unless there is an additional different top level directory you wish to exclude. Make sure you use an editor that is linux friendly and does not add carriage returns to the ends of lines. (edit the file using "mc" and you'll be fine)

The normalized values are set by many manufacturers on a brand new disk to either 253 or 200. Once the disk has some use, these change to their starting points, usually 100 or 200. All the lines with changes are just that initial set to the beginning "normalized" values once the disk have been in use for a short time. The only "raw" value that is humanly-understandable in your output is the number of times the disk heads were loaded onto the disk platters. That incremented by 1. (and that is expected, since if the disks heads had not moved from the parked position onto the disk platters, it would not have been able to read or write the disk at all.)

Looks perfectly normal.

Not so easy. Let's try an example. Parity = 1TB Data 1 = 1TB Data 2 = 500Gig To make this easy, all the data bits on the 1TB drive are "1" On the 500Gig drive, only the first bit is a "1", the remaining are "0" Ok, for this exercise, here are the bits Conventional Calculation data1 data2 parity Address 0 11111111 10000000 01111111 Address 1 11111111 00000000 11111111 Address 500G 11111111 00000000 11111111 Address 500G+1 11111111 00000000 11111111 Your proposed method data1 data2 parity Address 0 11111111 00000000 11111111 Address 1 11111111 00000000 11111111 Address 250G 11111111 00000000 11111111 Address 500G 11111111 10000000 01111111 Address 500G+1 11111111 00000000 11111111 Address 750G 11111111 00000000 11111111 Now... We will replace the 500Gig drive with a 750 Gig drive because the 500Gig drive failed. data1 data2 parity Address 0 11111111 00000000 11111111 Address 1 11111111 00000000 11111111 Address 250G 11111111 XXXXXXXX 11111111 <- to calculate this byte, we need parity and data-1 from the 500G addresses but, as soon as we put it into place, then this line's parity is wrong and will also need changing. (The new data-2 byte will be 1000000 and the new parity 011111111) Address 500G 11111111 XXXXXXXX 01111111 Address 500G+1 11111111 XXXXXXXX 11111111 Address 750G 11111111 00000000 11111111 When we try to shift downward, we need to not only calculate the new data byte, but also new parity on the entire set of data drives for that same byte position. In other words, we need to read the entire set of bytes on the original offset, AND the entire set of bytes on the new byte offset and seek between them. This will take over twice as long as sequential reads of the set of disks. There goes your 20% savings.

Interesting concept.

All that cache_dirs attempts to do is keep the directory entries in the buffer cache by accessing them periodically. If you use your buffer cache by running other processes, or watching a movie, then it is easily possible for the least recently accessed entries to be displaced. have you tried running cache_dirs in the foreground to see where it is spending its time? Try the -F and -v options together like this cache_dirs -F -v You may have a larger hierarchy than it can handle, or you might be experiencing the side effects of spinup groups.

Read back about 6 posts or so. You are looking at a diff between the smart report before the preclear and after. http://lime-technology.com/forum/index.php?topic=4068.msg48756#msg48756 Your disk is fine. Joe L.

Exactly. They are coming from the user-file-system. It is complaining since it can only let you access one of the duplicated files. cache_dirs has no idea of the dupes existence.

Cache dirs does nothing different than using your windows-explorer to list the files in the directories. Duplicate files create log file entries when directories containing them are browsed, no matter how they are browsed. Filling up the syslog (using up all free ram) will eventually crash a system. There is nothing cache_dirs can do to fix the cause of running out of memory. Perhaps I can think of a way to disable it when free memory gets low. (But by then, you have other problems anyway)

cache_dirs only operates on /mnt/disk1 through /mnt/disk19 and /mnt/cache. It does not need to exclude a disk not in the array since it does not cache them.

That is why you can limit the number of levels cached, and why you can exclude folders where the spin-up delay is not an issue. I have only 512 Meg of ram in my server.

You know... you are the first to describe this behavior since I posted the last version of cache_dirs. Guess what. In adding the feature to suspend the script during the "mover" scripts operation, I broke cache_dirs. It is supposed to spit_back info as it ran. It is broken if you do not have a cache drive defined, as you discovered, a major part of the loop is skipped and no detail is printed. Since last October, over 200 people have downloaded it, and you are the first to notice the problem. (indirectly, at least) Thanks so much for the report of the problem you were having. I'm just attached a newer version of cache_dirs to the first post in its thread. I'll go hang my head in shame for my logic oversight.... for a few minutes anyway. Version 1.6.5 is now attached to the first post in this thread. It should work as you expected. Joe L.

Perhaps you'll be willing to zip up a copy of your s3.sh script and attach it to this thread. I can update the wiki. Joe L.

Type ls -lq /boot/custom and show us the output.

"sleep 5" is simply a 5 second pause in the script at that point. It has nothing to do with the server going to "sleep" It has nothing to to with 5 minutes. The 5 minutes is "created" by looping 5 times in a loop with a 60 second pause in the script each time through the loop. The basic logic is initialize a timeout variable to 5 (timeout=5) initialize a counter variable to 5 (count=5) loop (forever) if none of the disk drives is active decrement the counter variable by 1. else one of more disk drives is spinning set the counter to the "timeout" value. if the counter has decremented to zero (we've been through the loop 5 times, delaying 60 seconds each time, with all disks idle) pause for 5 seconds (I've no idea why this is needed. probably is not needed at all) sync the disks invoke beep-down echo 3 >/proc/acpi/sleep At this point, the server goes to sleep and the script does not continue until it is awakened. time passes..... The sever is awakened Post sleep activities to set up ethernet speed, WOL invoke /boot/config/been-up (should this be beep-up, instead of been-up?? ) reset the counter to 5 once more. delay 5 seconds more (again, not really needed) pause 60 seconds before looping and testing if all the drives are idle once more. go back to the top of the loop.

To flush all the disk buffers to the physical disks, just issue a sync command prior to the "echo 3 >/proc/acpi/sleep" That should take care of any concerns about parity being consistent across the disks.

It means your disk is running very hot 44C. Most people try to keep them below 40C. Other than that, see here: http://lime-technology.com/forum/index.php?topic=4068.msg36786#msg36786