[GUIDE] Fix the IntelliPark bug on a My Cloud

That’s not a particularly high load cycle count… The Reds are guaranteed to at least 600,000.

rac8006 wrote:

Check the /var/log/user.log to see how long your disk is in standby.

Thanks for your reply. Could you briefly explain how standby time is related to the 8-second head park bug? Cheers.

TonyPh12345 wrote:
That’s not a particularly high load cycle count… The Reds are guaranteed to at least 600,000.

It’s more than it would be if the bug were not present, and it’s unneeded wear and tear on the drive.  You’ll recall this is the same bug that made everybody hate the WD Greens.

Well I’ve seen on my system that when the disk enters standby 8 seconds later it wakes up again.  On a system that is

idle like over night.  The standby times should be in the thousands of seconds.  But with the current MY Cloud system it seems to wake up way to often.  The number that follows after is the number of seconds that the drive was a sleep.

I’ve found two problems with the disk standby.  One is that the system seems to always be writing to disk.  The other is that the system seems to be waking up to frequently.  I used the following script to display when the disk was written.

copy these line to a check.sh file.  Then do sh check.sh 10

This will display the diskstats file and show in the last three columns the number of data written.  When all three columns are 0 for ten minutes the disk will enter standby.

while :; do
iow_root=awk -v disk="md1" '{if ($3==disk) print $10}' /proc/diskstats
ior_datavol=awk -v disk="sda4" '{if ($3==disk) print $6}' /proc/diskstats
iow_datavol=awk -v disk="sda4" '{if ($3==disk) print $10}' /proc/diskstats
d=date +%k-%M-%S
let a=iow_root-iow_rootold
let b=ior_datavol-ior_datavolold
let c=iow_datavol-iow_datavolold
let x=a+b+c
if [“$x” -gt “0”]; then
echo $d “root” $iow_root “rdatavol” $ior_datavol “wdatavol” $iow_datavol $a $b $c;
fi

iow_rootold=$iow_root
iow_datavolold=$iow_datavol
ior_datavolold=$ior_datavol
sleep $1
done

In trying to execute Sleep1.awk, I am getting the following response:   

-bash ./sleep1.awk: Permission denied

Any suggestions.

Tim

Sorry.  do a chmod 755 sleep1.awk

RAC

perfect…tnx

tim

new info added.

My hdparm output is:

WDMyCloud:# hdparm -J /dev/sda

/dev/sda:
 wdidle3 = 300 secs

So I can assume I don’t have this bug? However, when executing the sleep1.awk script, I do have multiple 8’s in my output:

Apr 7 10:30:08 10:30:47 39 0:00:39
Apr 7 10:40:59 11:06:24 1525 0:25:25
Apr 7 11:16:36 11:17:06 30 0:00:30
Apr 7 11:27:18 11:40:06 768 0:12:48
Apr 7 12:00:29 12:00:37 8 0:00:08
Apr 7 12:10:48 12:15:07 258 0:04:18
Apr 7 12:25:18 12:31:17 359 0:05:59
Apr 7 12:41:29 12:41:36 7 0:00:07
Apr 7 12:51:48 12:59:10 442 0:07:22
Apr 7 13:11:24 13:11:32 8 0:00:08
Apr 7 13:21:43 13:25:06 203 0:03:23
Apr 7 13:35:18 13:40:15 297 0:04:57
Apr 7 13:50:27 13:50:43 16 0:00:16
Apr 7 14:11:07 14:11:15 8 0:00:08
Apr 7 14:21:26 15:30:31 4145 1:09:05
Apr 7 15:40:43 15:45:59 316 0:05:16
Apr 7 16:11:26 16:11:33 7 0:00:07
Apr 7 16:21:45 16:21:53 8 0:00:08
Apr 7 16:32:05 16:32:13 8 0:00:08
Apr 7 16:50:34 16:50:42 8 0:00:08
Apr 7 17:00:53 17:01:01 8 0:00:08
Apr 7 17:11:13 17:17:06 353 0:05:53
Apr 7 17:27:18 17:40:44 806 0:13:26
Apr 7 17:50:56 17:51:04 8 0:00:08
Apr 7 18:13:30 18:13:38 8 0:00:08
Apr 7 18:23:49 18:28:04 255 0:04:15

Should I be worried? (I don’t really understand what to make of the output)

https://packages.debian.org/wheezy/armhf/idle3-tools/download

 The install process gave a bunch of warnings, which I don’t know how to interpret.

Is that download built using a 64k page size…?

http://community.wd.com/t5/WD-My-Cloud/GUIDE-Building-packages-for-the-new-firmware-someone-tried-it/td-p/768007

cpt_paranoia wrote:

 

Is that download built using a 64k page size…?

Dunno, how do I tell?  I’m running firmware 3.x, though.

If you’re running V3 firmware, it shouldn’t be a problem, as I understand it.

I’d assume anything on the Debian release site would be built with the default 4k page size, hence the need for 64k build repositories for the MyCloud from the likes of Fox_exe.

Figured it out, and created guide.

So mine on fw 4.x. Without this patch…it does have the 8 sec bug but it still tends to sleep throuhout the night…From my log, I do have a cron job that runs at 30 min mark every 3 hours though!

Apr 12 23:19:38 nas1 logger: exit standby after 8 (since 2015-04-12 23:19:30.881129000 -0400)
Apr 12 23:26:08 nas1 logger: exit standby after 23 (since 2015-04-12 23:25:45.431129001 -0400)
Apr 12 23:34:22 nas1 logger: exit standby after 7 (since 2015-04-12 23:34:15.219908001 -0400)
Apr 12 23:44:55 nas1 logger: exit standby after 266 (since 2015-04-12 23:40:29.469908001 -0400)
Apr 13 02:00:08 nas1 logger: exit standby after 7747 (since 2015-04-12 23:51:01.719908001 -0400)
Apr 13 03:00:08 nas1 logger: exit standby after 3233 (since 2015-04-13 02:06:15.479908001 -0400)
Apr 13 03:05:03 nas1 logger: disable lazy init
Apr 13 03:17:01 nas1 logger: exit standby after 8 (since 2015-04-13 03:16:53.469908001 -0400)
Apr 13 03:23:22 nas1 logger: exit standby after 15 (since 2015-04-13 03:23:07.879908001 -0400)
Apr 13 04:40:08 nas1 logger: exit standby after 3934 (since 2015-04-13 03:34:34.599908001 -0400)
Apr 13 08:31:40 nas1 logger: exit standby after 13525 (since 2015-04-13 04:46:15.439908001 -0400)
Apr 13 10:08:35 nas1 logger: exit standby after 5448 (since 2015-04-13 08:37:47.599908001 -0400)

The Hdparm shows me the following:

nas1:/var/log# hdparm -J /dev/sda

/dev/sda:
wdidle3 = 300 secs (or 13.8 secs for older drives)

so, my result is

/dev/sda:
 wdidle3      = 8.0 secs

But, when I run the sleep1.awk code I get this:

WDMyCloud1:/var/log# tail -30 /var/log/user.log|./sleep1.awk
Apr 14 16:07:09 16:15:10   481  0:08:01
Apr 14 16:25:15 16:35:10   595  0:09:55
Apr 14 16:45:15 16:55:07   592  0:09:52
Apr 14 17:05:12 17:23:39  1107  0:18:27
Apr 14 17:33:44 18:12:44  2340  0:39:00
Apr 14 18:46:11 18:46:19     8  0:00:08
Total Sleep Time:  1:00:08

So, I’m wondering if i have the 8.0 sec bug why is the drive managing to sleep?

I’ve provided a couple of sections of my user.log.  Currently my My Cloud is doing nothing.  It may or may not be shared on my laptop during these times.  I’m not sure when I disconnected the drive on my laptop.  But samba is very busy even when nothing is being done on the system.  I’m trying to determine what samba is done.  So far I’ve found that it updates the ctime for the /var/cache/samba/browse.dat file about every 10 minutes or so.

This is my system running samba.

Apr 12 00:01:16 00:02:06    50  0:00:50
Apr 12 00:12:16 00:15:26   190  0:03:10
Apr 12 00:25:36 00:27:30   114  0:01:54
Apr 12 00:37:40 00:39:37   117  0:01:57
Apr 12 00:49:47 00:51:41   114  0:01:54
Apr 12 01:01:51 01:03:46   115  0:01:55
Apr 12 01:13:56 01:15:55   118  0:01:58
Apr 12 01:26:05 01:27:03    58  0:00:58
Apr 12 01:37:14 01:42:08   293  0:04:53
Apr 12 02:10:37 02:12:13    95  0:01:35
Apr 12 02:22:23 02:24:15   112  0:01:52
Apr 12 02:34:25 03:00:12  1546  0:25:46
Apr 12 03:15:26 03:15:34     8  0:00:08
Apr 12 03:35:55 03:36:41    46  0:00:46
Apr 12 03:46:51 03:51:53   302  0:05:02
Apr 12 04:32:36 04:34:03    87  0:01:27
Apr 12 04:44:13 04:46:05   112  0:01:52
Apr 12 04:56:15 04:58:12   117  0:01:57
Apr 12 05:08:22 05:10:12   110  0:01:50
Apr 12 05:20:22 05:22:14   112  0:01:52
Apr 12 05:32:24 05:34:16   112  0:01:52
Apr 12 05:44:26 05:46:17   110  0:01:50
Apr 12 05:56:27 05:58:24   117  0:01:57
Apr 12 06:08:34 06:10:26   112  0:01:52
Apr 12 06:20:36 06:22:29   113  0:01:53
Apr 12 06:32:39 06:34:30   111  0:01:51
Apr 12 06:44:40 06:46:33   113  0:01:53
Apr 12 06:56:43 06:58:37   114  0:01:54
Apr 12 07:08:47 07:10:43   116  0:01:56
Apr 12 07:20:53 07:22:45   112  0:01:52
Apr 12 07:32:55 07:34:47   112  0:01:52
Apr 12 07:44:57 07:46:54   117  0:01:57
Apr 12 07:57:04 07:59:01   117  0:01:57
Apr 12 08:19:23 08:20:32    69  0:01:09
Apr 12 08:30:42 08:35:46   304  0:05:04
Apr 12 09:16:28 09:18:01    93  0:01:33
Apr 12 09:28:11 09:30:19   128  0:02:08
Apr 12 09:40:29 09:42:25   116  0:01:56
Apr 12 09:52:35 09:54:29   114  0:01:54
Apr 12 10:04:39 10:06:37   118  0:01:58
Apr 12 10:16:47 10:18:41   114  0:01:54
Apr 12 10:28:51 10:30:48   117  0:01:57
Apr 12 10:51:09 10:54:59   230  0:03:50
Apr 12 11:05:10 11:07:04   114  0:01:54
Apr 12 11:17:14 11:19:09   115  0:01:55
Apr 12 11:49:40 11:55:22   342  0:05:42
Apr 12 12:05:33 12:12:13   400  0:06:40

This is my system without samba running.

Apr 14 23:58:14 02:38:37  9623  2:40:23
Apr 14 02:48:47 03:00:11   684  0:11:24
Apr 14 03:15:16 06:37:19 12123  3:22:03
Apr 14 06:47:30 10:03:55 11785  3:16:25
Apr 14 11:11:16 11:11:24     8  0:00:08
Apr 14 11:21:34 11:21:41     6  0:00:06
Apr 14 11:31:56 11:32:04     8  0:00:08
Apr 14 11:42:14 14:24:46  9752  2:42:32

More information about I/O activity while samba is running.  This is a trace of I/O for /dev/md1.  As you can see this is not much I/O in 1856 seconds.  No writes in this time frame.  The next trace is just of writes done in 1789 seconds.  The kjournald writes are writes to the filesystem journal.  The flush-9.1 are when data is flushed out to disk.

Am I the only one seeing that the disk does not sleep much when samba is running.  When I talked to WD support they

said that it didnt matter if the drive does not sleep sense they is desiged to run all the time.  My car can run 24 hours a day.  But I don’t leave it idling when i’m not using it.

  9,1    1        1     0.000000000 11220  Q  RM 1736712 + 8 [monitorio.sh]
  9,1    1        2     0.021721499 11220  Q  RM 1736744 + 8 [monitorio.sh]
  9,1    1        3     0.037318100 11222  Q   R 1753120 + 8 [cat]
  9,1    1        4     0.069944170 11224  Q   R 2788088 + 8 [df]
  9,1    0        1    10.665129780 11308  Q   R 2793128 + 8 [grep]
  9,1    1        5    10.670922600 11310  Q   R 2573752 + 8 [grep]
  9,1    1        6    10.677596065 11309  Q   R 2796568 + 8 [ls]
  9,1    0        2    10.680551880 11311  Q   R 2790776 + 8 [sed]
  9,1    1        7    10.696631265 11310  Q   R 2573920 + 8 [grep]
  9,1    0        3    11.052052904 11336  Q   R 3122376 + 8 [find]
  9,1    0        4    11.073770760 11336  Q   R 2553416 + 128 [find]
  9,1    0        5    11.073851380 11336  Q   R 2553544 + 128 [find]
  9,1    1        8    11.106559680 11342  Q   R 3261184 + 8 [tr]
  9,1    1        9    11.171188570 11344  Q   R 2798056 + 8 [touch]
  9,1    1       10    11.416879040 11363  Q   R 1493432 + 48 [mdadm]
  9,1    0        6    11.468948610 11368  Q   R 2791088 + 8 [rm]
  9,1    0        7    15.593399595   417  Q  WS 1616136 + 8 [kjournald]
  9,1    0        8    15.618901635   417  Q  WS 1616144 + 8 [kjournald]
  9,1    0        9    15.619333065   417  Q WBS 1616152 + 8 [kjournald]
  9,1    0       10    50.493348100 10901  Q   W 263152 + 8 [flush-9:1]
  9,1    0       11    61.331933529 11378  Q   R 3238064 + 16 [awk]
  9,1    0       12    61.398781980 11383  Q   R 2787944 + 8 [cat]
  9,1    1       11    61.493110379 11389  Q   R 3231624 + 8 [xargs]
  9,1    1       12    61.501337089 11389  Q   R 3231664 + 8 [xargs]
  9,1    1       13    61.636589875 11392  Q   R 2786864 + 40 [sh]
  9,1    1       14    62.183898720 11428  Q   R 3209912 + 8 [cut]
  9,1    1       15    62.506342260 11446  Q   R 3756592 + 8 [smartctl]
  9,1    1       16    62.528581140 11446  Q   R 3720056 + 128 [smartctl]
  9,1    0       13    62.730351530 11449  Q   R 2796856 + 8 [sleep]
  9,1    0       14   734.621493704 12173  Q   R 2794264 + 8 [date]
  9,1    0       15   734.621973024 12173  Q   R 2794304 + 8 [date]
  9,1    0       16   734.636935085 12174  Q   R 1492504 + 136 [hdparm]
  9,1    1       17   748.326622640 12210  Q   R 3251704 + 8 [stat]
  9,1    1       18   748.368507205 12210  Q   R 3251744 + 8 [stat]
  9,1    1       19  1113.252708434 12570  Q  RM 3165520 + 8 [sh]
  9,1    0       17  1126.097877870 12632  Q  RM 3247376 + 8 [sh]
  9,1    1       20  1132.461047520 12635  Q   R 2553160 + 128 [awk]
  9,1    1       21  1132.461113030 12635  Q   R 2553288 + 128 [awk]
  9,1    0       18  1760.070899440 13328  Q  RM 1736704 + 8 [ls]
  9,1    0       19  1760.091557344 13328  Q  RM 1806592 + 8 [ls]
  9,1    0       20  1760.103520315 13328  Q  RM 2162688 + 8 [ls]
  9,1    0       21  1811.678619725 13576  Q   R 2788088 + 8 [df]
  9,1    0       22  1856.202189939 13604  Q   R 3121576 + 8 [getRunLevel.pl]
  9,1    0       23  1856.224286115 13604  Q   R 3121616 + 8 [getRunLevel.pl]
  9,1    0       24  1856.226256345 13604  Q   R 2950904 + 128 [getRunLevel.pl]
  9,1    0       25  1856.378248980 13606  Q   R 1487456 + 8 [runlevel]
  9,1    0       26  1856.419391340 13608  Q   R 3156728 + 8 [expr]
  9,1    0       27  1856.438768670 13608  Q   R 3156768 + 8 [expr]

 These are just the writes done in 1789 seconds

9,1 0 1 5.532680031 417 Q WS 1597536 + 8 [kjournald]
9,1 0 2 5.571569145 417 Q WS 1597544 + 8 [kjournald]
9,1 0 3 5.571930985 417 Q WBS 1597552 + 8 [kjournald]
9,1 1 4 11.532816481 417 Q WS 1597560 + 8 [kjournald]
9,1 1 5 11.562073985 417 Q WS 1597568 + 8 [kjournald]
9,1 0 4 11.562469250 417 Q WBS 1597576 + 8 [kjournald]
9,1 0 5 25.062365875 417 Q WS 1597584 + 8 [kjournald]
9,1 0 6 25.074632561 417 Q WS 1597592 + 8 [kjournald]
9,1 0 7 25.075022186 417 Q WBS 1597600 + 8 [kjournald]
9,1 1 13 30.532631396 417 Q WS 1597608 + 8 [kjournald]
9,1 1 14 30.554592581 417 Q WS 1597616 + 8 [kjournald]
9,1 1 15 30.554959931 417 Q WBS 1597624 + 8 [kjournald]
9,1 1 16 39.982593141 6792 Q W 3146096 + 8 [flush-9:1]
9,1 0 11 298.532581891 417 Q WS 2417672 + 8 [kjournald]
9,1 0 12 298.554649106 417 Q WS 1597632 + 8 [kjournald]
9,1 0 13 298.554673171 417 Q WS 1597640 + 8 [kjournald]
9,1 0 14 298.554681256 417 Q WS 1597648 + 8 [kjournald]
9,1 0 15 298.554688186 417 Q WS 1597656 + 8 [kjournald]
9,1 0 16 298.554694501 417 Q WS 1597664 + 8 [kjournald]
9,1 0 17 298.554701466 417 Q WS 1597672 + 8 [kjournald]
9,1 0 18 298.554708136 417 Q WS 1597680 + 8 [kjournald]
9,1 0 19 298.555331371 417 Q WBS 1597688 + 8 [kjournald]
9,1 0 20 328.572637716 417 Q WBS 1597696 + 8 [kjournald]
9,1 0 21 332.582586316 6792 Q W 0 + 8 [flush-9:1]
9,1 0 22 332.601167130 6792 Q W 8 + 8 [flush-9:1]
9,1 0 23 332.601200125 6792 Q W 2097160 + 8 [flush-9:1]
9,1 0 24 332.601219225 6792 Q W 2098688 + 8 [flush-9:1]
9,1 0 25 332.601237235 6792 Q W 2162688 + 8 [flush-9:1]
9,1 0 26 332.601256440 6792 Q W 2360288 + 8 [flush-9:1]
9,1 0 43 1015.572617441 417 Q WS 2417640 + 8 [kjournald]
9,1 0 44 1025.670731750 417 Q WS 1597704 + 8 [kjournald]
9,1 0 45 1025.670776105 417 Q WS 1597712 + 8 [kjournald]
9,1 0 46 1025.670801080 417 Q WS 1597720 + 8 [kjournald]
9,1 0 47 1025.670809160 417 Q WS 1597728 + 8 [kjournald]
9,1 0 48 1025.670817440 417 Q WS 1597736 + 8 [kjournald]
9,1 0 49 1025.670825080 417 Q WS 1597744 + 8 [kjournald]
9,1 0 50 1025.670832975 417 Q WS 1597752 + 8 [kjournald]
9,1 0 51 1025.671947020 417 Q WBS 1597760 + 8 [kjournald]
9,1 0 70 1045.572625051 417 Q WBS 1597768 + 8 [kjournald]
9,1 0 71 1060.292582521 8684 Q W 2360288 + 8 [flush-9:1]
9,1 0 72 1060.310939040 8684 Q W 0 + 8 [flush-9:1]
9,1 0 73 1060.310951060 8684 Q W 8 + 8 [flush-9:1]
9,1 0 74 1060.310970690 8684 Q W 2097160 + 8 [flush-9:1]
9,1 0 75 1060.310989265 8684 Q W 2098688 + 8 [flush-9:1]
9,1 0 76 1060.311006980 8684 Q W 2162688 + 8 [flush-9:1]
9,1 1 42 1744.532566146 417 Q WS 2417672 + 8 [kjournald]
9,1 0 77 1754.607626905 417 Q WS 1597776 + 8 [kjournald]
9,1 0 78 1754.607679410 417 Q WS 1597784 + 8 [kjournald]
9,1 0 79 1754.607690070 417 Q WS 1597792 + 8 [kjournald]
9,1 0 80 1754.607713205 417 Q WS 1597800 + 8 [kjournald]
9,1 0 81 1754.607720650 417 Q WS 1597808 + 8 [kjournald]
9,1 0 82 1754.607727970 417 Q WS 1597816 + 8 [kjournald]
9,1 0 83 1754.607734785 417 Q WS 1597824 + 8 [kjournald]
9,1 0 84 1754.608616825 417 Q WBS 1597832 + 8 [kjournald]
9,1 0 85 1774.562622236 417 Q WBS 1597840 + 8 [kjournald]
9,1 0 86 1789.452585636 9471 Q W 2162688 + 8 [flush-9:1]
9,1 0 87 1789.476443846 9471 Q W 2360288 + 8 [flush-9:1]
9,1 0 88 1789.476486626 9471 Q W 0 + 8 [flush-9:1]
9,1 0 89 1789.476495141 9471 Q W 8 + 8 [flush-9:1]
9,1 0 90 1789.476512386 9471 Q W 2097160 + 8 [flush-9:1]
9,1 0 91 1789.476529506 9471 Q W 2098688 + 8 [flush-9:1]

dubie wrote:

 

So, I’m wondering if i have the 8.0 sec bug why is the drive managing to sleep?

I don’t believe Intellipark is related to the sleep timer; it just parks the heads (unnecessarily.) 

For me, the ongoing wakeups are another project.  I’ve disabled a boatload of services thus far, but I just don’t know enough about Linux to figure out why it keeps waking up, aside from the cron jobs.

I have that same output:

WDmycloud# hdparm -J /dev/sda
/dev/sda:
 wdidle3 = 300 secs (or 13.8 secs for older drives)

So what does this mean?

…so having only very recently realised that my device (WD Cloud 1st Gen) is impacted by this bug, and only once I started using HD Sentinel to monitor it:

I am most grateful that I dug out this thread, managed to install idle3ctl yesterday evening - one link above is not valid anymore but I did manage to source this armhf.deb file from elsewhere - and managed to change the timer on this HDD accordingly.

FWIW: my Load Cycle Count (SMART #193) reached nearly 6M - not bad (and quite scary either!) for ~9 year old device that runs 24/7, isn’t it?

What kind-of accelerated my actions were other SMART values of this HDD that started changing: Read Error Rate (#01) & Spin-Up Time (#03) that suddenly jumped a bit in the last year - indicating that this HDD might be on its way out soon.

I also managed to buy second device (hardly used by the looks of it - and its HDD’s SMART values as well), and I endeavour to swap the HDD to the larger one (10-14TB) at some stage in the future once this one eventually fails.
→ I did also spot that HDD firmware revision on the second device was newer (82.00A82 as opposed to 80.00A80 on mine) - and so were its timer settings either (300 seconds as opposed to 8 seconds on mine).

Needless to say all stuff’s backed up as needed.