Yes, WD should be actively fixing issues with their firmware. And no, they don’t.
Yep, that is the very frustrating part. There has long been a well discussed problems with the My Cloud sleep feature that have gone unfixed. Making things worse is they apparently may have updated samba (still not the latest version) in this firmware version and now that is causing some sort of sleep problems for some of us. None of the previous sleep hacks are working for me, my unit rarely sleeps more than 10 percent of the time now so long as samba is running.
I use Samba exclusively, which led me to abandon .315 very quickly.
On a positive note, once I rolled back to .101, I went after it with a vengeance and am now getting the best sleep times I’ve ever had. On the downside, my upload speed is faster than my download speed, and I can’t figure out how to stop the logs from rotating every day.
Well looks like the mount didn’t fix my problem. It started out sleeping better. But then started to wake up about every 15 minutes. Back to the drawing board.
Just for information. In the Gen2 (latest version) I had the MyCloud sleeping then wakup after every 15min then after 10min sleep an so on. I saw in the logs the the device was communicating with their central like a keep alive. After disabling cloud access the drive sleep started behaving normally.
v04.05.00-315 was horrible for sleep times:
2017-05-03T12:59:33.250960+02:00 di=H10IhkTgem notice logger: exit standby after 589 (since 2017-05-03 12:49:44.666754001 +0200)
2017-05-03T13:29:33.396500+02:00 di=H10IhkTgem notice logger: exit standby after 579 (since 2017-05-03 13:19:54.506754001 +0200)
2017-05-03T13:59:33.310211+02:00 di=H10IhkTgem notice logger: exit standby after 579 (since 2017-05-03 13:49:54.676754001 +0200)
2017-05-03T14:29:33.403603+02:00 di=H10IhkTgem notice logger: exit standby after 579 (since 2017-05-03 14:19:54.436754001 +0200)
2017-05-03T14:59:33.268551+02:00 di=H10IhkTgem notice logger: exit standby after 579 (since 2017-05-03 14:49:54.656754001 +0200)
2017-05-03T15:29:33.299851+02:00 di=H10IhkTgem notice logger: exit standby after 579 (since 2017-05-03 15:19:54.506754001 +0200)
2017-05-03T15:59:33.290764+02:00 di=H10IhkTgem notice logger: exit standby after 579 (since 2017-05-03 15:49:54.456754001 +0200)
2017-05-03T16:29:33.256608+02:00 di=H10IhkTgem notice logger: exit standby after 579 (since 2017-05-03 16:19:54.516754001 +0200)
2017-05-03T16:59:33.272441+02:00 di=H10IhkTgem notice logger: exit standby after 579 (since 2017-05-03 16:49:54.596754001 +0200)
2017-05-03T17:29:33.300484+02:00 di=H10IhkTgem notice logger: exit standby after 579 (since 2017-05-03 17:19:54.546754001 +0200)
2017-05-03T17:59:33.298605+02:00 di=H10IhkTgem notice logger: exit standby after 579 (since 2017-05-03 17:49:54.496754001 +0200)
2017-05-03T18:02:36.753787+02:00 di=H10IhkTgem notice logger: calculate_share_size after 3
2017-05-03T18:51:51.205357+02:00 di=H10IhkTgem notice logger: exit standby after 8 (since 2017-05-03 18:51:43.596754001 +0200)
2017-05-03T19:14:33.291975+02:00 di=H10IhkTgem notice logger: exit standby after 141 (since 2017-05-03 19:12:12.476754001 +0200)
2017-05-03T19:44:32.834899+02:00 di=H10IhkTgem notice logger: exit standby after 578 (since 2017-05-03 19:34:54.666754001 +0200)
2017-05-03T20:14:33.020676+02:00 di=H10IhkTgem notice logger: exit standby after 578 (since 2017-05-03 20:04:54.186754001 +0200)
2017-05-03T20:44:33.215255+02:00 di=H10IhkTgem notice logger: exit standby after 579 (since 2017-05-03 20:34:54.326754001 +0200)
2017-05-03T21:14:33.275292+02:00 di=H10IhkTgem notice logger: exit standby after 579 (since 2017-05-03 21:04:54.496754001 +0200)
2017-05-03T21:44:33.275628+02:00 di=H10IhkTgem notice logger: exit standby after 579 (since 2017-05-03 21:34:54.566754001 +0200)
2017-05-03T22:14:33.287351+02:00 di=H10IhkTgem notice logger: exit standby after 579 (since 2017-05-03 22:04:54.506754001 +0200)
2017-05-03T22:44:33.300822+02:00 di=H10IhkTgem notice logger: exit standby after 579 (since 2017-05-03 22:34:54.566754001 +0200)
2017-05-03T23:14:33.282779+02:00 di=H10IhkTgem notice logger: exit standby after 579 (since 2017-05-03 23:04:54.566754001 +0200)
2017-05-03T23:44:33.254354+02:00 di=H10IhkTgem notice logger: exit standby after 579 (since 2017-05-03 23:34:54.536754001 +0200)
I downgraded to version: v04.04.05-101 following: WD My Cloud v3.x, v4.x and v2.x Firmware Versions Download Links and the problem is already gone:
2017-05-04T03:45:42.955809+02:00 di=H10IhkTgem notice logger: exit standby after 730 (since 2017-05-04 03:33:32.782046002 +0200)
2017-05-04T11:26:28.444026+02:00 di=H10IhkTgem notice logger: exit standby after 27035 (since 2017-05-04 03:55:53.762046002 +0200)
Thanks to @rac8006 help ( WD My Cloud randomly wakes up the drive when Drive Sleep is enabled ), I use the modified file /CacheVolume/user-start with the following content:
mount -o remount,noatime,nodiratime /dev/root /
I don’t use the remote access, that’s why I disabled all those services. Disabling cron didn’t cause any problems for me, for over 1 year.
Yes, back to the drawing board. So far the only solution I’ve found for my unit is to disable Samba. Otherwise the unit doesn’t sleep like it did with earlier firmware. I may roll back the firmware until a fix is found.
Love how fixing one problem introduces another.
I think I know why the mount command did not fix the problem. When looking at the blktrace output. I found that about every 900 seconds. a block of about 8 writes to the Kjournal was being done. These 8 blocks consisted of a bitmap block, a directory entry block, two inode blocks along with a header and trailer block for Kjournal. This output is being caused by samba creating a new socket. Last night in the /etc/samba/msg.sock folder was four entries created when samba first started. But it also had one additional entry. Whose number was much higher that the original four entries created at startup. This morning that entry is not there. In its place is another entry about a thousand higher than last night. These are sockets I think. This number I think is a pid(process id) of the process that created the socket. I posted a question on the samba group. They responded that four sockets were opened at startup and closed when samba exits.
@rac8006 Thanks for your efforts! (Even if i honestly don’t understand everything you said)
Perhaps you can try to mount /etc/samba/msg.sock as ramdisk folder? So the writing won’t wake up the disk?
kill the cron. If you are still on gen1 then you can actually deactivate it like you do with the scans.
I had cron off for years and never had any problems. If you are concerned that the logs may be filling up, you can either reboot or just turn on cron and let it run for a week, then turn it back off.
That was the response that I got from the samba group. They said make a ramdisk. So
that is what I’m currently testing. It rook a couple of tried to get the correct commands.
But msg.sock is now on a tmpfs. Will need to run it for a while to make sure it is working.
Good to hear, after a lot of reading i am currently testing
mount -t tmpfs -o mode=0700,noatime,size=2m tmpfs /etc/samba/msg.sock/
Again thanks to rac8006 for his investigation!
Changes seem to work, i get very good sleep times now! (Until now my longest sleep time was 4:47 minutes with this firmware, if you look at my older posts)
05 05 01:01:00 07:09:34 22114 6:08:34 <--My ssh login woke it up! :) 05 05 07:35:06 07:35:34 28 0:00:28 05 05 08:19:24 08:43:49 1465 0:24:25 05 05 09:04:15 09:05:01 46 0:00:46 05 05 09:25:26 12:55:52 12626 3:30:26 <-- Here i turned off my PC, 05 05 13:16:17 14:14:05 3468 0:57:48 only one wake up while i was away
(My standby time begins after 20 minutes in standby,conf)
Here is my user startup-script:
/etc/init.d/samba stop mount -t tmpfs -o mode=0700,noatime,size=2m tmpfs /etc/samba/msg.sock/ /etc/init.d/samba start mount -o remount,noatime,nodiratime /dev/root / /etc/init.d/cron stop
I don’t know if we really need the noatime remount of root, or the stopping of cron…
Will test the mount tmpfs msg.sock code on a v4 as well to see if it improves sleep times as a further data point.
What I did was very similar to what you did. Though I didn’t do the noatime. Currently I don’t see the same times as you. Since the change I don’t see the kjournal entires any more. But I do see the smbd code being read more than
I’ve seen in the past. I’m going to turn the log level back to zero in the smb-global.conf file. Not sure if the debugging is causing the need to read smbd code over and over again.
Looking at your sleep times. I don’t see the 03:00 wake up that normally occurs. Do you have cron stopped? You still need the nodirtime and noatime on root.
Yes, cron is disabled in the startscript.
I didn’t change anything in the samba config.
I only set the log level so I could see what samba was doing. It is not necessary. I will check later today to see if the extra logging was causing the reads.
PS There is a known memory leak in samba 4.3.11. Fixed in 4.3.13.
So WD have rolled out a version of SMB with a known memory leak bug…? On a 24/7 file server…?
Nice. Very professional…
I don’t know if WD knew that there was a memory leak. I first saw references to the leak yesterday. I signed up for the samba group mailing list way back.
Okay. I might forgive them…