DrKK
FreeNAS Generalissimo
- Joined
- Oct 15, 2013
- Messages
- 3,630
So, I typically rock WD reds in my FreeNAS's.
I used to use some WD blue's, however, on a HTPC box which also doubled as a backup system to my NAS. After I made my new NAS last summer, which was considerably larger, those 4TB blues I had in that backup system were no longer large enough, on their own, to be useful. So, I took the old FreeNAS mobo, put it in a bigger case, pressed my 3x2TB reds from the old box, *AND* the 2x4TB blues from the backup system, into a mixed zpool, installed FreeNAS, and made *THAT* my backup box. I also use the backup box to test FreeNAS 11.
So. FreeNAS11 has a "daemon.log" in /var/log. "Hmph, interesting!" say I. And I look at it. Among the various things it records, are any changes in the interpreted values of your SMART parameters. And lo and behold, the "load cycle" parameter is dropping precipitously, by a unit or two PER DAY, on the blues, which are in the system as ada0 and ada1. Sure enough, gives me the bad news. I have 250000 load cycles now on those blues. "Wow, that's going way faster than I thought". Not a minute later, I run the same command. The load cycles have GONE UP BY SIX, in just that time. "OK, this is a job for that wdidle3.exe stuff I keep hearing about". And come to discover---no, not really, these guys can't be set by wdidle3--many of the newer drives from WD cannot. Whooooooops.
"Well, I guess I better access something on this drive like 12 times a minute then." So, we need a script to do that. After being inspired by some ideas I saw online (forgive me---I don't mean to plagiarize, but I didn't pay close attention to who exactly suggested what), I decided to run a never-ending bash script. bash is nice because it has a $RANDOM in there, which can be used to strong effect. Here's what I came up with (i.e., mostly stole from the kind of thing I saw others do), which is now running in the background at all times, and indeed, it stopped the load-cycle counter dead in its tracks:
So, unpacking that a little, I set a file name to store in the temp directory. We then have the infinite loop, which first expresses a disenfranchising emotion about the necessity to have this script in the first place. It then calls command-line bash and makes "clever"(?) use of dd to read a block from some random place on ada0, then the same on ada1. This counts as a legitimate access of the specific drives which should stop the parking timer, and just redirects that stuff to devnull. As for echo I put a random number at the end of the file? I have no idea. One of the scripts I saw online from someone that seemed smart (no pun intended) put it there, and so whatever, I put it in there, I figure it can't hurt to access the pool and a second time for a file write. Then I sleep for 4 seconds, and repeat. I suspect 4 could probably be raised somewhat. But whatever. Doesn't matter.
End result is that instead of the load counter going up by 10 per minute (or worse), it hasn't gone up at all for hours now.
You'll want to backgroundize this and/or stick it in as a script to execute upon startup, etc., lest you forget to run the script next time you reboot.
Anyway. yeah, there you go. It's not particularly elegant, but I'd have been at a million load cycles in no time without something like this.
Enjoy.
I used to use some WD blue's, however, on a HTPC box which also doubled as a backup system to my NAS. After I made my new NAS last summer, which was considerably larger, those 4TB blues I had in that backup system were no longer large enough, on their own, to be useful. So, I took the old FreeNAS mobo, put it in a bigger case, pressed my 3x2TB reds from the old box, *AND* the 2x4TB blues from the backup system, into a mixed zpool, installed FreeNAS, and made *THAT* my backup box. I also use the backup box to test FreeNAS 11.
So. FreeNAS11 has a "daemon.log" in /var/log. "Hmph, interesting!" say I. And I look at it. Among the various things it records, are any changes in the interpreted values of your SMART parameters. And lo and behold, the "load cycle" parameter is dropping precipitously, by a unit or two PER DAY, on the blues, which are in the system as ada0 and ada1. Sure enough,
Code:
smartctl -a /dev/ada0 | grep Load_Cycle
"Well, I guess I better access something on this drive like 12 times a minute then." So, we need a script to do that. After being inspired by some ideas I saw online (forgive me---I don't mean to plagiarize, but I didn't pay close attention to who exactly suggested what), I decided to run a never-ending bash script. bash is nice because it has a $RANDOM in there, which can be used to strong effect. Here's what I came up with (i.e., mostly stole from the kind of thing I saw others do), which is now running in the background at all times, and indeed, it stopped the load-cycle counter dead in its tracks:
Code:
#!/bin/bash
FILE=/tmp/lccprevent.txt
while true
do
/bin/echo "Western Digital Greens and Blues should die in a fire." > $FILE
/bin/bash -c '/bin/dd if=/dev/ada0 of=/dev/null count=1 skip=${RANDOM}'
/bin/bash -c '/bin/dd if=/dev/ada1 of=/dev/null count=1 skip=${RANDOM}'
/bin/bash -c '/bin/echo ${RANDOM}' >> $FILE
/bin/sleep 4
done
So, unpacking that a little, I set a file name to store in the temp directory. We then have the infinite loop, which first expresses a disenfranchising emotion about the necessity to have this script in the first place. It then calls command-line bash and makes "clever"(?) use of dd to read a block from some random place on ada0, then the same on ada1. This counts as a legitimate access of the specific drives which should stop the parking timer, and just redirects that stuff to devnull. As for echo I put a random number at the end of the file? I have no idea. One of the scripts I saw online from someone that seemed smart (no pun intended) put it there, and so whatever, I put it in there, I figure it can't hurt to access the pool and a second time for a file write. Then I sleep for 4 seconds, and repeat. I suspect 4 could probably be raised somewhat. But whatever. Doesn't matter.
End result is that instead of the load counter going up by 10 per minute (or worse), it hasn't gone up at all for hours now.
You'll want to backgroundize this and/or stick it in as a script to execute upon startup, etc., lest you forget to run the script next time you reboot.
Anyway. yeah, there you go. It's not particularly elegant, but I'd have been at a million load cycles in no time without something like this.
Enjoy.
Last edited:
