Why is it that the /dev/md1 partition is mounted with noatime and nodiratime, but the root partition is
mounted with relatime? When I changed the root partition to match the /dev/md1 partition. My system
entered standby at 7:30pm. It woke up at 0:10 AM and at 03:00 AM due to cron and was sleeping when
I logged on at 10:06 AM. This is on a system that is not being used for any work yet. Before I changed
the root partition and before the new firmware release it would wake up multiple times after only sleeping
for a minute or two. Some times after only 8 seconds.
RAC
According to our Moderators this forum is for the user community only with no WD tech people reading; hopefully a moderator will pass this along but generally when you ask such a question none of us (the community) can answer with any resolution.
However, now that you have discovered this workaround, I think I can guess the reason. Lets bring the mounting options over from the other post.
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
So from looking at our mouting options, relatime is the norm which is the answer to your question of why they used it.
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.
Changing it to noatime implying nodiratime means never update atime of any file or directory.
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).
Nice workaround, however I need to check if I need atime updates 
Ralphael
What you say is true. Part of my question was why did WD setup /dev/md1 in the /etc/fstab to have those
options. But not in /dev/root?
good quesiton and
I can only guess that /dev/root is your main mount which includes your shares, where-as any others they decided to forego atime since there was no need.
In the worst case, not updating atime can cause some backup programs to fail to back up a file… hmmmm but if you don’t change it or modify the file, you do not need to back up the file… soooo… yeah…
nice workaround!! seriously
Never mind, I just found the script mountDataVolume.sh
show me your fstab Rac006 and I’ll show you mine (version 3.04 firmware)
proc /proc proc defaults 0 0
sysfs /sys sysfs defaults 0 0
found that Access DLNA can sometimes temporarily use up to 70M of the /tmp space
increasing to 100M maximum
tmpfs /tmp tmpfs rw,size=100M 0 0
mount cgroup hierarchy
cgroup /sys/fs/cgroup cgroup memory,cpu 0 0
/dev/md1 / ext3 defaults,noatime,nodiratime,data=writeback,barrier=0 0 0
I don’t have any /dev/root and I think this has changed in your version
Ralphael
I’m not familiar with raid. I’m not even sure how to explain the setup. But /dev/md1 is really sda1 and sda2. Root
is also sda1 and sda1.
Not sure why a backup program would use atime. You would think it would use mtime or ctime. I think I read
that mail programs may use atime to know that mail has been read. There is also the ability to set noatime on
a file by file basis.
My fstab is the same as yours no /dev/root but
Do a cat /proc/mounts.
RAC
To confirm what you just said… “Yes they are, we knew that all this time :-P” but it is a possibility that they mounted them with different mounts just for the reason of access.
anyways lets get to you listing what you changed to get noatime on dev/root?
I think this is a great workaround.
hey Rac8006
time to post up “How”, in other words show us what you did to make that noatime change…
No idea why Rac8006 doesn’t respond nor post up his findings…
but here is how you can change /dev/root into noatime
-
ssh into your device
-
mount -o remount,noatime /dev/root /
This is not a permanent change, in other words if you reboot, the change is gone.
Now remember that there are no warrantees nor guarantees from issuing this command. If it works for you… great… if not and something doesn’t get backed up… too bad…
Post up on your sleep time if this works!! and go give some kudos to Rac8006 for finding this workaround.
Ralphael
I couldn’t respond because I was out of the house until now. Once in awhile I do leave the computer. Though my wife
would disagree. My response would have been.
mount -o remount,noatime,nodiratime /dev/root /
This is what I have both systems currently mounted.
I also emailed a question to WD asking why the difference.
RAC
I had assumed we were having a “posting” conversation this morning
anyways before I left the house at 12:45, I had remounted my root with noatime.
mount shows the following for root
/dev/root on / type ext3 (rw,noatime,errors=continue,barrier=1,data=ordered)
however I don’t have as many process “canceled” as you do rac8006 so my timing turned out to be as follows
May 14 13:42:37 WDMyCloud logger: exit standby after 3397 (since 2015-05-14 12:45:55.888573001 -0700)
May 14 14:29:46 WDMyCloud logger: exit standby after 2522 (since 2015-05-14 13:47:39.668573001 -0700)
May 14 14:52:33 WDMyCloud logger: exit standby after 1059 (since 2015-05-14 14:34:49.578573001 -0700)
May 14 16:32:55 WDMyCloud logger: exit standby after 5714 (since 2015-05-14 14:57:36.508573001 -0700)
I just got home at 4:32pm. So not exactly the whole answer I was looking for, but probably better then if it wasn’t set to noatime. I was hoping that most programs was just reading with no ctime or mtime and thus no wakeups despite having more jobs running.
Good enough, better than before.
Another small win for the users…
Ralphael
I you want to investigate further. I could give you the blktrace and blkparse programs. Wait you are still
on version 3.04. I guess you could start by stopping the same processes that I have stopped. To see
if things change. Understand on my system are basically out of the box. I have not had time to set them
up for real work.
If the version of code that you are using is standard. You may be able to get these programs using apt-get
install blktrace. This program would allow you to trace the I/O’s being issued. I also would suggest for you
to add a couple of lines to monitorio.sh. Add the logger lines at the two locations. These two lines will display
the value of the variables that the monitorio.sh watches before entering standby. It logs the variables when it wakes up and when it enters standby.
dmesg -c
fi
logger “iow_root=$iow_root iow_datavol=$iow_datavol ior_datavol=$ior_datavol”
while :; do
Wait for 60 seconds
sleep 60
touch /tmp/standby
logger “iow_root=$iow_root iow_datavol=$iow_datavol ior_datavol=$ior_datavol”
sync <======= new solution, this sync seems to work better
sync <======= new solution, this sync seems to work better
sleep 5 <======= sleep 5 seconds waiting for the access to settle
RAC
Well done Rac8006,
I was looking at the i/o tools last year and I really didn’t want to apt-get on my cloud just in case I overwrote something incompatible.
I did however, modify monitorio.sh as you had suggested watching the values of the variables that monitorio monitors before it went into standby and watching the variables coming out of standby and even logged the output of ps -ALL to see what programs were active at the time of wakeup, I had suspected the touch and some logging was causing the 5 second flush that woke up the drive.
So I was, and probably still am, giving up on all this as it is good enough; for the most part it sleeps and this noatime puts the final nail in the cloud :-P
I will add the additional sync to my monitorio and if I’m energetic enough I might dust off my own monitorio.sh program and add in the hours, minutes and seconds conversion to the exit log time so I can read it easier; that might be the extent of my venture back into the sleep problem of WD Cloud.
Thanks for the info and if you find out something more exciting, keep posting and I’ll read it later.
-----------------edited
Ok, I just checked my sleeping drive. I left for the gym at 5:00pm and now at 7:49 I see
May 14 17:17:09 WDMyCloud logger: exit standby after 1015 (since 2015-05-14 17:00:09.858573001 -0700)
May 14 18:24:15 WDMyCloud logger: exit standby after 3719 (since 2015-05-14 17:22:11.748573001 -0700)
May 14 19:49:05 WDMyCloud logger: exit standby after 4783 (since 2015-05-14 18:29:17.678573001 -0700)
The one thing I noticed is, the 5, 10, 20 seconds wakeups are gone. Now the wake up time is 17 minutes, 1 hour and the last one is 1 hour and 20 minutes.
Nice!!
Ralphael
Why not just use the sleep.awk script. It gives you the sleep time in hours/minutes/seconds.
RAC
RAC - Why not just use the sleep.awk script. It gives you the sleep time in hours/minutes/seconds.
I could … but if I am going to dust off my monitorio program, might as well make it log elegantly 
