NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Readynas OS 6.6 drives wont spindown
Hi, I recently upgraded to OS6.6 on my RN104, never had a problem with disk spindown before but soon as I have upgraded the disks dont really spindown anymore, they spindown for about 10 seconds then...
The "noflushd" we use on ReadyNAS is heavily modified, and is vastly different from the noflushd you may read about on the internet. Our version is RAID-aware, and of course works with journaling filesystems. Otherwise you'd never see disks spin down for longer than 30 seconds.
Writes to the filesystem are not a problem, unless they are synchronous writes. The flush to disk gets deferred until the disks *really* need to spin up, like for a sync write or a read request. So writing to a log file, or dirtying inodes, will not make the disks spin up.
Thanks for the explanation Skywalker, makes sense.
I've ran my modded versions of spin{up,down}.sh for two days now. And it still writes to disk for no reason just during spin down, these three instances for example:
Oct 14 12:00:27 backup noflushd[3375]: Spinning down disk 1 (/dev/sda). Oct 14 12:00:29 backup noflushd[3375]: Spinning down disk 2 (/dev/sdb). Oct 14 12:00:37 backup noflushd[3375]: Spinning up disk 1 (/dev/sda) after 0:00:08. Oct 14 12:00:37 backup noflushd[3375]: Spinning up disk 2 (/dev/sdb) after 0:00:05. Oct 14 12:15:38 backup noflushd[3375]: Spinning down disk 1 (/dev/sda). Oct 14 12:15:40 backup noflushd[3375]: Spinning down disk 2 (/dev/sdb). Oct 14 12:15:47 backup noflushd[3375]: Spinning up disk 1 (/dev/sda) after 0:00:07. Oct 14 12:15:47 backup noflushd[3375]: Spinning up disk 2 (/dev/sdb) after 0:00:05. Oct 14 12:30:48 backup noflushd[3375]: Spinning down disk 1 (/dev/sda). Oct 14 12:30:50 backup noflushd[3375]: Spinning down disk 2 (/dev/sdb).
With the block dumps for each (the last was successful?):
okt 14 12:00:39: jbd2/md0-8(887): WRITE block 3686872 on md0 (8 sectors)
okt 14 12:00:39: md0_raid1(872): WRITE block 8 on sda1 (1 sectors)
okt 14 12:00:39: md0_raid1(872): WRITE block 8 on sdb1 (1 sectors)
okt 14 12:00:41: jbd2/md0-8(887): WRITE block 3686880 on md0 (8 sectors)
okt 14 12:00:41: jbd2/md0-8(887): WRITE block 3686888 on md0 (8 sectors)
okt 14 12:00:41: jbd2/md0-8(887): WRITE block 3686896 on md0 (8 sectors)
okt 14 12:00:41: md0_raid1(872): WRITE block 8 on sda1 (1 sectors)
okt 14 12:00:41: md0_raid1(872): WRITE block 8 on sdb1 (1 sectors)
okt 14 12:15:50: jbd2/md0-8(887): WRITE block 3687048 on md0 (8 sectors)
okt 14 12:15:50: md0_raid1(872): WRITE block 8 on sda1 (1 sectors)
okt 14 12:15:50: md0_raid1(872): WRITE block 8 on sdb1 (1 sectors)
okt 14 12:15:52: jbd2/md0-8(887): WRITE block 3687056 on md0 (8 sectors)
okt 14 12:15:52: jbd2/md0-8(887): WRITE block 3687064 on md0 (8 sectors)
okt 14 12:15:52: jbd2/md0-8(887): WRITE block 3687072 on md0 (8 sectors)
okt 14 12:15:52: md0_raid1(872): WRITE block 8 on sda1 (1 sectors)
okt 14 12:15:52: md0_raid1(872): WRITE block 8 on sdb1 (1 sectors)
okt 14 12:30:54: jbd2/md0-8(887): WRITE block 3687304 on md0 (8 sectors)
okt 14 12:30:54: md0_raid1(872): WRITE block 8 on sda1 (1 sectors)
okt 14 12:30:54: md0_raid1(872): WRITE block 8 on sdb1 (1 sectors)
I have about 15 spinups daily, 5 of which I can explain (updating software, doing backups etc).
Maybe the modified noflushd needs some kind of grace period (or synchronous wait) before spinning down the drives to let the writes settle? Because, I still feel that there is a race here.
We are looking into the issues that have been reported with disk spin-down on ARM systems.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
