Bagpuss

I'm glad to hear you say that. I was genuinely confused by what it's doing. I'll give it one more preclear, and see what happens. I've not had chance to look for a firmware update, so I'll give that a try too. At the end of the day, it's a recycled drive from an old Dell laptop, so no great loss if it doesn't work. Thanks again for your help.

Hi Rob, Attached is a SMART report after a long SMART test. There doesn't appear to be much different in the report that I can see, apart from certain error counts going up. Would really appreciate it if you could take a look at the new report. Thanks, Andy. smart.afterlongtest.txt

Thanks for getting back to me, Rob. With regards to the operational hours etc., then it's entirely possible that these figures are accurate, as the drive was a pull from a defunct primary (elementary) school laptop. It's quite likely that it could have been turned on and off regulary in very short sessions. I'll try running a long SMART test, and see what happens.

Hi All, I've just done a preclear on a 120GB 2.5" drive that I was intending to use as a cache drive in a small unRAID system that I'm building for a friend. I've done 3 pre-clear cycles on the drive, and on each subsequent cycle, the number of sectors pending re-allocation has increased by 112. I've attached the pre-clear reports, and would appreciate an opinion on the condition of this drive. Thanks, Andy. preclear_rpt__S14PJD0Q752009_2013-07-25.txt preclear_start__S14PJD0Q752009_2013-07-25.txt preclear_finish__S14PJD0Q752009_2013-07-25.txt

Thanks very much for the rapid reply. I think I'll run another pre-clear on that drive, and then monitor it closely.

Hi All, Just had a slightly suspect pre-clear report (my first, thankfully) and I'd really appreciate an opinion on this particular disk. I was planning to run another pre-clear to see if I get the same result, but haven't done this yet. My concern is around some UNC reads and writes that are logged on the drive. I've included the pre and post SMART results, as well as the pre-clear report. The thing that I'm concerning about is that the sectors pending re-allocation have gone down following pre-clear. I was sort of expecting that these sectors would have been re-allocated. pre-clear report ========================================================================1.13 == invoked as: ./preclear_disk.sh -A /dev/sdc == WDC WD30EZRX-00MMMB0 WD-WMAWZXXXXXXX == Disk /dev/sdc has been successfully precleared == with a starting sector of 1 == Ran 1 cycle == == Using :Read block size = 8225280 Bytes == Last Cycle's Pre Read Time : 9:16:43 (89 MB/s) == Last Cycle's Zeroing time : 9:02:10 (92 MB/s) == Last Cycle's Post Read Time : 21:30:38 (38 MB/s) == Last Cycle's Total Time : 39:50:31 == == Total Elapsed Time 39:50:31 == == Disk Start Temperature: 24C == == Current Disk Temperature: 32C, == ============================================================================ ** Changed attributes in files: /tmp/smart_start_sdc /tmp/smart_finish_sdc ATTRIBUTE NEW_VAL OLD_VAL FAILURE_THRESHOLD STATUS RAW_VALUE Seek_Error_Rate = 100 200 0 ok 0 Temperature_Celsius = 120 128 0 ok 32 No SMART attributes are FAILING_NOW 7 sectors were pending re-allocation before the start of the preclear. 7 sectors were pending re-allocation after pre-read in cycle 1 of 1. 0 sectors were pending re-allocation after zero of disk in cycle 1 of 1. 0 sectors are pending re-allocation at the end of the preclear, a change of -7 in the number of sectors pending re-allocation. 0 sectors had been re-allocated before the start of the preclear. 0 sectors are re-allocated at the end of the preclear, the number of sectors re-allocated did not change. ============================================================================ I've attached the SMART reports, as they were too large to be posted as part of the message content. Any thoughts on this would be much appreciated. Andy. preclear_finish.txt preclear_start.txt

Hi Julian, I've spotted the same problems with this script on my unRAID box. I've attached a fixed version, which ignores activity on the cache drive. I've not noticed any side effects of this on my machine, and I've been running the script for 3 months now. Also, the checking for idle network activity is broken, and has been from the start. The current test for idle network is: TCP=$(bwm-ng -o csv -c 1 -d 0 -T avg | grep eth0 | cut -d";" -f5) However, this fails to take into account that the avg function in bwm-ng needs sample data over multiple seconds to calculate an average. When you repeatedly run this command in a shell, you will find that 7 times out of 10, it returns 0.00, even when the network is very busy. I was finding that my server was going to sleep at really odd times, when I knew that downloading/uploading was in full flow. Expecting 0.00 for average network activity is unrealistic, unless the machine is unplugged from the network. There is always some kind of network housekeeping going on, even in a very small network. To fix the problem, I've changed the test to this: TCP=$(bwm-ng -o csv -c 30 -d 0 -t 1000 -T avg | grep eth0 | cut -d";" -f5 | tail -1 | sed 's/.\{3\}$//') This does two things. Firstly, we move to a 1 second sample interval, and take 30 samples to calculate our average. Secondly, I've moved to integers for reporting the network activity. The fractions were not significant in determining activity, so it seemed pointless to test them. The complete new function is as follows: check_TCP_activity() { if [ "$checkTCP" = $yes ] then # Previous test for this failed to acknowledge that first value from bwm-ng is nearly always 0 # when using -c 1. A true average is only calculated if you let bwm-ng run multiple times. # New test sets sample interval to 1 second and takes 30 samples, returning the last one for testing. # On my system, even when completely idle, you still see approx 5-6KB/s total network activity. # Expectng 0.00 activity is unrealistic, unless machine is unplugged from the network. # Have also moved to integers, as the fractions are unimportant in this test. TCP=$(bwm-ng -o csv -c 30 -d 0 -t 1000 -T avg | grep eth0 | cut -d";" -f5 | tail -1 | sed 's/.\{3\}$//') else TCP="$noTCP" fi echo $TCP } In addition, I've also added a couple of other features: 1) Debug logging Possible options are: # Enable debug logging # debug=0 - no logging # debug=1 - logs to syslog and auto_s3_sleep.log # debug=2 - logs to syslog # debug=3 - logs to auto_s3_sleep.log # debug=4 - log to console Simply edit the script, and change the debug= line to one of the values above (depending on what you want). The default is 'debug=1'. 2) Shell activity checking. Options are set in these lines: checkSSH=$yes # check for any SSH connections checkSHELL=$no # check for any locally logged in sessions (if "no" allows console debugging) This allows you to prevent the machine from sleeping if someone is logged in over ssh, at the console, or both. The default is to prevent sleep if someone is logged in over SSH, but allow it if they are logged in at the console. I've not had a single 'false' sleep, since making these changes. I've also attached a simple script which runs the 'sleep' checks, and reports on whether the system will go to sleep when the countdown timer expires. I keep meaning to add a 'test' option to the main script, but I've never got around to it. Hope this is useful for you. Andy. auto_s3_sleep.sh.zip test_sleep_conditions.sh.zip