Rac8006,
I think you are on the right track… so lets clarify for the laymans of this forum.
From en.wikipedia.org
Reading a file changes its atime eventually requiring a disk write, which has been criticized as it is inconsistent with a read only file system. This behaviour can usually be disabled by adding the noatime mount option in /etc/fstab. Turning off atime updating breaks POSIX compliance, and some applications, such as mbox-driven “new mail” notifications, [4] and some file usage watching utilities, notably tmpwatch. Linux kernel developer Ingo Molnár called atime “perhaps the most stupid Unix design idea of all times,” [5] [6] adding: “[T]hink about this a bit: ‘For every file that is read from the disk, let’s do a … write to the disk! And, for every file that is already cached and which we read from the cache … do a write to the disk!’” He further emphasized the performance impact thus:
atime updates are by far the biggest I/O performance deficiency that Linux has today. Getting rid of atime updates would give us more everyday Linux performance than all the pagecache speedups of the past 10 years, _combined_.
File system cache may significantly reduce this activity to one disk write per cache flush.
Solutions[edit]
Current versions of Linux, Mac OS X, Solaris, FreeBSD, NetBSD, and OpenBSD support a noatime mount option, which causes the atime field never to be updated. This breaks compliance with POSIX.
Current versions of the Linux kernel support four mount options, which can be specified in fstab:
- strictatime (formerly atime, and formerly the default; strictatime as of 2.6.30) – always update atime
- relatime (“relative atime”, introduced in 2.6.20 and the default as of 2.6.30) – only update atime under certain circumstances (explained below)
- nodiratime – never update atime of directories, but do update atime of other files
- noatime – never update atime of any file or directory; implies nodiratime; highest performance, but least compatible
-
strictatime accords with POSIX. File systems mounted with the noatime option do not update the atime on reads, while the relatime option provides for updates only if the previous atime is older than the mtime or ctime, or the previous atime is over 24 hours in the past. Many users use noatime without problem, so long as they do not use an application which depends on atime, and this offers some benefits over relatime (no writing of atime ever on read).
Now how this pertains to the WD Cloud is that the cloud is built using the linux system, so even when nothing is happening, system logs are always being written however WD has isolated most of these logs and has created a ramdisk to isolate most activities to memory but not all.
Even monitorio.sh is guilty using echo >file to write a date-time.file as well as touch date-time file to keep the last date-time stamp before the drive is set to standby using hdparm -y.
After a certain build-up of unwritten data, the system will wake suddenly to flush out the data to disk. This will occur several times from 2 seconds to several minutes after the disk has gone into standby; then the system will sleep for several hours at a time (provided that you have switched off the scans as well as the cron).
I’ve tried using “sync” in monitorio to no avail. At first I thought I saw a decrease in the number of initial wake-ups and sometimes it was true, that theory went to **bleep** last year when I got consistent wake-ups at every 25 minutes indicating that some wake-ups are coming from outside and this was the time when the WD server was having problems.
I gave up…
however do continue your research… perhaps it may be as simple as remounting a logging ramdisk with noatime.
when I first copied the user.log file over to the shares, i did not have permission to read it from my Mac, so I just did a chmod to all bit on which includes making it an executable 
