<7>kjournald(183): WRITE block 11648 on md3
<7>kjournald(183): WRITE block 11656 on md3
<7>kjournald(183): WRITE block 11664 on md3
<7>kjournald(183): WRITE block 11672 on md3
<7>pdflush(36): WRITE block 0 on md3
<7>pdflush(36): WRITE block 8 on md3
<7>pdflush(36): WRITE block 1572864 on md3
<7>pdflush(36): WRITE block 1572872 on md3
<7>pdflush(36): WRITE block 1572880 on md3
<7>pdflush(36): WRITE block 1576744 on md3
<7>md1_raid1(174): WRITE block 5879552 on sda1
<7>md3_raid1(170): WRITE block 1975808 on sda3
<7>kjournald(175): WRITE block 147504 on md1
<7>md1_raid1(174): WRITE block 5879552 on sda1
<7>kjournald(175): WRITE block 10048 on md1
<7>kjournald(175): WRITE block 10056 on md1
<7>kjournald(175): WRITE block 10064 on md1
<7>md1_raid1(174): WRITE block 5879552 on sda1
<7>pdflush(37): WRITE block 1464 on md1
<7>md1_raid1(174): WRITE block 5879552 on sda1
<7>pdflush(36): WRITE block 1474560 on md3
<7>md3_raid1(170): WRITE block 1975808 on sda3
<7>pdflush(36): WRITE block 1474568 on md3
<7>pdflush(36): WRITE block 1474576 on md3
<7>pdflush(36): WRITE block 1474584 on md3

how can i stop them so my MBW dont spin up and down 3 times an hour, the MBW often only spin down for 2 minutes and then it spin ud again, i have tried alot, but i dosent work

What can i do ? plz help im a bit noob on linux

I've followed kyyhkynen's guides and end up with disk-spinup each hour. I've modified the spindown script so it clears dmesg and spinup script so it dumps the dmesg to a file with timestamp. Please help me disable whatever is causing the disk access. The logs are very similar to theese two:

<7>ntpd(780): dirtied inode 12 (?) on ram1
<7>ntpd(780): dirtied inode 2 (/) on ram1
<7>ntpd(780): dirtied inode 2 (/) on ram1
<7>ntpd(780): dirtied inode 33 (ntp.drift) on ram1
<7>sh(7415): dirtied inode 46380 (now) on md3
<7>kjournald(183): WRITE block 901128 on md3
<7>md3_raid1(170): WRITE block 1975808 on sda3
<7>kjournald(183): WRITE block 5520 on md3
<7>kjournald(183): WRITE block 5528 on md3
<7>kjournald(183): WRITE block 5536 on md3
<7>kjournald(183): WRITE block 5544 on md3
<7>kjournald(183): WRITE block 5552 on md3
<7>kjournald(183): WRITE block 5560 on md3
<7>md3_raid1(170): WRITE block 1975808 on sda3
<7>cp(7420): dirtied inode 19923 (ntp.drift) on md1
<7>S13ramdisk(7419): dirtied inode 30 (locks) on ram1
<7>cp(7421): dirtied inode 92743 (account_policy.tdb) on md3
<7>cp(7421): dirtied inode 31 (account_policy.tdb) on ram1
<7>cp(7421): dirtied inode 92747 (brlock.tdb) on md3
<7>cp(7421): dirtied inode 32 (brlock.tdb) on ram1
<7>cp(7421): dirtied inode 92742 (browse.dat) on md3
<7>cp(7421): dirtied inode 56 (browse.dat) on ram1
<7>cp(7421): dirtied inode 92746 (connections.tdb) on md3
<7>cp(7421): dirtied inode 34 (connections.tdb) on ram1
<7>cp(7421): dirtied inode 92749 (gencache.tdb) on md3
<7>cp(7421): dirtied inode 35 (gencache.tdb) on ram1
<7>cp(7421): dirtied inode 92744 (group_mapping.tdb) on md3
<7>cp(7421): dirtied inode 36 (group_mapping.tdb) on ram1
<7>cp(7421): dirtied inode 92748 (locking.tdb) on md3
<7>cp(7421): dirtied inode 37 (locking.tdb) on ram1
<7>cp(7421): dirtied inode 92741 (messages.tdb) on md3
<7>cp(7421): dirtied inode 38 (messages.tdb) on ram1
<7>cp(7421): dirtied inode 92740 (nmbd.pid) on md3
<7>cp(7421): dirtied inode 39 (nmbd.pid) on ram1
<7>cp(7421): dirtied inode 92753 (ntdrivers.tdb) on md3
<7>cp(7421): dirtied inode 40 (ntdrivers.tdb) on ram1
<7>cp(7421): dirtied inode 92755 (ntforms.tdb) on md3
<7>cp(7421): dirtied inode 41 (ntforms.tdb) on ram1
<7>cp(7421): dirtied inode 92754 (ntprinters.tdb) on md3
<7>cp(7421): dirtied inode 42 (ntprinters.tdb) on ram1
<7>cp(7421): dirtied inode 92750 (registry.tdb) on md3
<7>cp(7421): dirtied inode 43 (registry.tdb) on ram1
<7>cp(7421): dirtied inode 92745 (sessionid.tdb) on md3
<7>cp(7421): dirtied inode 44 (sessionid.tdb) on ram1
<7>cp(7421): dirtied inode 92756 (share_info.tdb) on md3
<7>cp(7421): dirtied inode 45 (share_info.tdb) on ram1
<7>cp(7421): dirtied inode 92758 (smbd.pid) on md3
<7>cp(7421): dirtied inode 46 (smbd.pid) on ram1
<7>cp(7421): dirtied inode 92757 (unexpected.tdb) on md3
<7>cp(7421): dirtied inode 47 (unexpected.tdb) on ram1
<7>cp(7422): dirtied inode 30945 (log.0.0.0.0) on md3
<7>cp(7422): dirtied inode 13 (log.0.0.0.0) on ram1
<7>cp(7422): dirtied inode 30942 (log.045bd-acc15x520) on md3
<7>cp(7422): dirtied inode 14 (log.045bd-acc15x520) on ram1
<7>cp(7422): dirtied inode 30943 (log.192.168.1.100) on md3
<7>cp(7422): dirtied inode 15 (log.192.168.1.100) on ram1
<7>cp(7422): dirtied inode 30947 (log.192.168.1.102) on md3
<7>cp(7422): dirtied inode 16 (log.192.168.1.102) on ram1
<7>cp(7422): dirtied inode 30946 (log.192.168.1.106) on md3
<7>cp(7422): dirtied inode 17 (log.192.168.1.106) on ram1
<7>cp(7422): dirtied inode 30941 (log.gert-inspiron-6) on md3
<7>cp(7422): dirtied inode 18 (log.gert-inspiron-6) on ram1
<7>cp(7422): dirtied inode 30925 (log.home-e65103366e) on md3
<7>cp(7422): dirtied inode 19 (log.home-e65103366e) on ram1
<7>cp(7422): dirtied inode 30930 (log.jacob-pc) on md3
<7>cp(7422): dirtied inode 20 (log.jacob-pc) on ram1
<7>cp(7422): dirtied inode 30932 (log.mac001b6337d39b) on md3
<7>cp(7422): dirtied inode 21 (log.mac001b6337d39b) on ram1
<7>cp(7422): dirtied inode 30919 (log.nmbd) on md3
<7>cp(7422): dirtied inode 22 (log.nmbd) on ram1
<7>cp(7422): dirtied inode 30929 (log.smbd) on md3
<7>cp(7422): dirtied inode 23 (log.smbd) on ram1
<7>cp(7422): dirtied inode 30924 (log.smbd.old) on md3
<7>cp(7422): dirtied inode 24 (log.smbd.old) on ram1
<7>cp(7422): dirtied inode 30940 (log.stuen) on md3
<7>cp(7422): dirtied inode 25 (log.stuen) on ram1
<7>cp(7422): dirtied inode 30926 (log.thomas-pc) on md3
<7>cp(7422): dirtied inode 26 (log.thomas-pc) on ram1
<7>cp(7422): dirtied inode 30928 (log.thomas-pc.old) on md3
<7>cp(7422): dirtied inode 27 (log.thomas-pc.old) on ram1
<7>cp(7422): dirtied inode 30927 (log.tj-dell) on md3
<7>cp(7422): dirtied inode 28 (log.tj-dell) on ram1
<7>cp(7422): dirtied inode 30944 (log.tj-dell.old) on md3
<7>cp(7422): dirtied inode 29 (log.tj-dell.old) on ram1
<7>S13ramdisk(7419): dirtied inode 48 (private) on ram1
<7>cp(7423): dirtied inode 61829 (lighttpd.htdigest.user) on md3
<7>cp(7423): dirtied inode 49 (lighttpd.htdigest.user) on ram1
<7>cp(7423): dirtied inode 61836 (secrets.tdb) on md3
<7>cp(7423): dirtied inode 50 (secrets.tdb) on ram1
<7>cp(7423): dirtied inode 61833 (smbpasswd) on md3
<7>cp(7423): dirtied inode 51 (smbpasswd) on ram1
SPINUP

<7>sh(22396): dirtied inode 46380 (now) on md3
<7>kjournald(183): WRITE block 983040 on md3
<7>md3_raid1(170): WRITE block 1975808 on sda3
<7>kjournald(183): WRITE block 7256 on md3
<7>kjournald(183): WRITE block 7264 on md3
<7>kjournald(183): WRITE block 7272 on md3
<7>kjournald(183): WRITE block 7280 on md3
<7>kjournald(183): WRITE block 7288 on md3
<7>kjournald(183): WRITE block 7296 on md3
<7>md3_raid1(170): WRITE block 1975808 on sda3
<7>cp(22401): dirtied inode 19923 (ntp.drift) on md1
<7>cp(22401): dirtied inode 12 (ntp.drift) on ram1
<7>S13ramdisk(22400): dirtied inode 30 (locks) on ram1
<7>cp(22402): dirtied inode 92743 (account_policy.tdb) on md3
<7>cp(22402): dirtied inode 31 (account_policy.tdb) on ram1
<7>cp(22402): dirtied inode 92747 (brlock.tdb) on md3
<7>cp(22402): dirtied inode 32 (brlock.tdb) on ram1
<7>cp(22402): dirtied inode 92742 (browse.dat) on md3
<7>cp(22402): dirtied inode 56 (browse.dat) on ram1
<7>cp(22402): dirtied inode 92746 (connections.tdb) on md3
<7>cp(22402): dirtied inode 34 (connections.tdb) on ram1
<7>cp(22402): dirtied inode 92749 (gencache.tdb) on md3
<7>cp(22402): dirtied inode 35 (gencache.tdb) on ram1
<7>cp(22402): dirtied inode 92744 (group_mapping.tdb) on md3
<7>cp(22402): dirtied inode 36 (group_mapping.tdb) on ram1
<7>cp(22402): dirtied inode 92748 (locking.tdb) on md3
<7>cp(22402): dirtied inode 37 (locking.tdb) on ram1
<7>cp(22402): dirtied inode 92741 (messages.tdb) on md3
<7>cp(22402): dirtied inode 38 (messages.tdb) on ram1
<7>cp(22402): dirtied inode 92740 (nmbd.pid) on md3
<7>cp(22402): dirtied inode 39 (nmbd.pid) on ram1
<7>cp(22402): dirtied inode 92753 (ntdrivers.tdb) on md3
<7>cp(22402): dirtied inode 40 (ntdrivers.tdb) on ram1
<7>cp(22402): dirtied inode 92755 (ntforms.tdb) on md3
<7>cp(22402): dirtied inode 41 (ntforms.tdb) on ram1
<7>cp(22402): dirtied inode 92754 (ntprinters.tdb) on md3
<7>cp(22402): dirtied inode 42 (ntprinters.tdb) on ram1
<7>cp(22402): dirtied inode 92750 (registry.tdb) on md3
<7>cp(22402): dirtied inode 43 (registry.tdb) on ram1
<7>cp(22402): dirtied inode 92745 (sessionid.tdb) on md3
<7>cp(22402): dirtied inode 44 (sessionid.tdb) on ram1
<7>cp(22402): dirtied inode 92756 (share_info.tdb) on md3
<7>cp(22402): dirtied inode 45 (share_info.tdb) on ram1
<7>cp(22402): dirtied inode 92758 (smbd.pid) on md3
<7>cp(22402): dirtied inode 46 (smbd.pid) on ram1
<7>cp(22402): dirtied inode 92757 (unexpected.tdb) on md3
<7>cp(22402): dirtied inode 47 (unexpected.tdb) on ram1
<7>S13ramdisk(22400): dirtied inode 2 (/) on ram1
<7>cp(22403): dirtied inode 30945 (log.0.0.0.0) on md3
<7>cp(22403): dirtied inode 13 (log.0.0.0.0) on ram1
<7>cp(22403): dirtied inode 30942 (log.045bd-acc15x520) on md3
<7>cp(22403): dirtied inode 14 (log.045bd-acc15x520) on ram1
<7>cp(22403): dirtied inode 30943 (log.192.168.1.100) on md3
<7>cp(22403): dirtied inode 15 (log.192.168.1.100) on ram1
<7>cp(22403): dirtied inode 30947 (log.192.168.1.102) on md3
<7>cp(22403): dirtied inode 16 (log.192.168.1.102) on ram1
<7>cp(22403): dirtied inode 30946 (log.192.168.1.106) on md3
<7>cp(22403): dirtied inode 17 (log.192.168.1.106) on ram1
<7>cp(22403): dirtied inode 30941 (log.gert-inspiron-6) on md3
<7>cp(22403): dirtied inode 18 (log.gert-inspiron-6) on ram1
<7>cp(22403): dirtied inode 30925 (log.home-e65103366e) on md3
<7>cp(22403): dirtied inode 19 (log.home-e65103366e) on ram1
<7>cp(22403): dirtied inode 30930 (log.jacob-pc) on md3
<7>cp(22403): dirtied inode 20 (log.jacob-pc) on ram1
<7>cp(22403): dirtied inode 30932 (log.mac001b6337d39b) on md3
<7>cp(22403): dirtied inode 21 (log.mac001b6337d39b) on ram1
<7>cp(22403): dirtied inode 30919 (log.nmbd) on md3
<7>cp(22403): dirtied inode 22 (log.nmbd) on ram1
<7>cp(22403): dirtied inode 30929 (log.smbd) on md3
<7>cp(22403): dirtied inode 23 (log.smbd) on ram1
<7>cp(22403): dirtied inode 30924 (log.smbd.old) on md3
<7>cp(22403): dirtied inode 24 (log.smbd.old) on ram1
<7>cp(22403): dirtied inode 30940 (log.stuen) on md3
<7>cp(22403): dirtied inode 25 (log.stuen) on ram1
<7>cp(22403): dirtied inode 30926 (log.thomas-pc) on md3
<7>cp(22403): dirtied inode 26 (log.thomas-pc) on ram1
<7>cp(22403): dirtied inode 30928 (log.thomas-pc.old) on md3
<7>cp(22403): dirtied inode 27 (log.thomas-pc.old) on ram1
<7>cp(22403): dirtied inode 30927 (log.tj-dell) on md3
<7>cp(22403): dirtied inode 28 (log.tj-dell) on ram1
<7>cp(22403): dirtied inode 30944 (log.tj-dell.old) on md3
<7>cp(22403): dirtied inode 29 (log.tj-dell.old) on ram1
<7>S13ramdisk(22400): dirtied inode 48 (private) on ram1
<7>cp(22404): dirtied inode 61829 (lighttpd.htdigest.user) on md3
<7>cp(22404): dirtied inode 49 (lighttpd.htdigest.user) on ram1
<7>cp(22404): dirtied inode 61836 (secrets.tdb) on md3
<7>cp(22404): dirtied inode 50 (secrets.tdb) on ram1
<7>cp(22404): dirtied inode 61833 (smbpasswd) on md3
<7>cp(22404): dirtied inode 51 (smbpasswd) on ram1
SPINUP

Please help ;)

Despite this, sometimes my mybook spins up, without any of my computers being on, and sometimes it does not shut down correct, but starts blinking and doesn't respons until I turn it off manually.

I enabled syslog again, but it doesn't have any crucial information in it (just that I logged in or something).

Is there any way to log what the mybook is really doing, what is triggering the spinup and what just happens before a crash?

[root@dlashorne src]# /usr/sbin/smart_spindown
Monitoring spindown opportunities for disks sda and sdb.
/dev/sdb: No such device or address
Both drives are currently spun down.
/dev/sdb: No such device or address
spindowns: 1, time up/down: 0/30, backoff 100, down for -1 (avg 30).

[root@dlashorne hdparm-7.7]# make
cc -O2 -W -Wall -Wbad-function-cast -Wcast-align -Wpointer-arith -Wcast-qual -Wshadow -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -fkeep-inline-functions -Wwrite-strings -Waggregate-return -Wnested-externs -Wtrigraphs -c -o hdparm.o hdparm.c
make: cc: Command not found
make: *** [hdparm.o] Error 127

i am not for sure that this is the problem but i have a feeling that it is.

Here's the commented out netbios-ssn line from /etc/inetd.conf (i.e. turning samba of in inetd)

# netbios-ssn stream tcp nowait root /usr/local/samba/sbin/smbd smbd -s/var/oxsemi/smb.conf -l/mnt/ramdisk/log -d0

Without the # character at the start of the line the inetd process would attempt to start smbd every time a packet arrive on the windows netbios port (139).

And here's samba.sh. My change is commented in the GWL (just my initials) section. You can also see how all the -l options for smbd and nmbd direct to /mnt/ramdisk.

(apologies for the dodgy indenting, it's the wiki software)

Hope it helps.

Thanks for detailing your description. I wonder if you would care also to show the lines to include in the samba.sh file - I'm not confident with this Linux stuff yet. Your additional fix seem highly relevant when using the hacked box as file server for Windows machines, maybe kyyhkynen who wrote the original guide would repeat your description or link to your post …

I'll describe the problem but please be aware that this was not a problem with spindown, or with creating the ramdisk. I just filled up the ramdisk too quickly.

For example:

I had smbd configured at first to run using inetd. This means that smbd is not running by default and only starts up when a request comes in on the windows networking port. Every time smbd started, it wrote a little welcome note to the log which cannot be turned off. Then a utility on windows was polling my networked samba drive EVERY MINUTE. It's only 180bytes or so each time but this very quickly filled up my samba logs. My solution was to ensure smbd was started once at boot time (my samba.sh script in /etc/init.d starts both nmbd and smbd ONCE!). I also set my samba config to
a. log to the ramdisk
b. limit the amount of logging to a minimum
b. limit the log file size to 25kB.

My smb.conf [global] section contains the following lines

log file = /mnt/ramdisk/log/log.%m
log level = 0
max log size = 25

Once you've created your ramdisk and followed the steps in the tutorial to send common logs to it, then you can check your disk activity log and see if anything's still causing problems.

Every time any process on your box creates a log message, it's forcing the disk to spin up. A ramdisk creates a small virtual disk in memory where these log files can be written to instead of spinnig up the physical harddisk.

The creation of the ramdisk is quite easy to do. The only hurdle I had at first was a problem with smbd quickly filling up the space which eventually stopped smbd from working. I could still use ssh to fix the problem though. just needed some tuning of logging levels.

I followed all the cool and quiet hacks succesfully. I didn't do the RAM disk as I don't know if I need it. I use a WD Mybook WE 500Gb as file repository for our Windows machines - and nothing else. Spin down does work now and then but I still have quite some activity going on. I'm completely new to Linux. Can someone help me understand what is going on and what can be stopped - and how? I can see Samba is running - but I don't know if I need it. The other stuff I don't really know what is. Activity log posted below - I think it covers around 15 minutes during which the Mybook did not spin down.

kassoe

<7>nmbd(613): dirtied inode 46395 (browse.dat.) on md3
<7>nmbd(613): dirtied inode 46394 (?) on md3
<7>kjournald(183): WRITE block 868568 on md3
<7>md3_raid1(170): WRITE block 1975808 on sda3
<7>kjournald(183): WRITE block 5408 on md3
<7>kjournald(183): WRITE block 5416 on md3
<7>kjournald(183): WRITE block 5424 on md3
<7>kjournald(183): WRITE block 5432 on md3
<7>kjournald(183): WRITE block 5440 on md3
<7>kjournald(183): WRITE block 5448 on md3
<7>kjournald(183): WRITE block 5456 on md3
<7>kjournald(183): WRITE block 5464 on md3
<7>md3_raid1(170): WRITE block 1975808 on sda3
<7>pdflush(36): WRITE block 0 on md3
<7>md3_raid1(170): WRITE block 1975808 on sda3
<7>pdflush(36): WRITE block 8 on md3
<7>pdflush(36): WRITE block 786928 on md3
<7>pdflush(36): WRITE block 786936 on md3
<7>pdflush(36): WRITE block 786944 on md3
<7>pdflush(36): WRITE block 950272 on md3
<7>kjournald(183): WRITE block 5472 on md3
<7>md3_raid1(170): WRITE block 1975808 on sda3
<7>smbd(980): dirtied inode 46375 (smbpasswd) on md3
<7>kjournald(183): WRITE block 5480 on md3
<7>md3_raid1(170): WRITE block 1975808 on sda3
<7>kjournald(183): WRITE block 5488 on md3
<7>kjournald(183): WRITE block 5496 on md3
<7>md3_raid1(170): WRITE block 1975808 on sda3
<7>pdflush(37): WRITE block 786944 on md3
<7>md3_raid1(170): WRITE block 1975808 on sda3
<7>md3_raid1(170): WRITE block 1975808 on sda3
<7>smbd(2479): dirtied inode 61840 (smbd) on md3
<7>smbd(2479): dirtied inode 61841 (log.smbd) on md3
<7>smbd(2479): dirtied inode 61841 (log.smbd) on md3
<7>smbd(2479): dirtied inode 61841 (log.smbd) on md3
<7>smbd(2479): dirtied inode 46375 (smbpasswd) on md3
<7>smbd(2479): dirtied inode 46385 (registry.tdb) on md3
<7>smbd(2479): dirtied inode 46381 (connections.tdb) on md3
<7>smbd(2479): dirtied inode 46389 (ntprinters.tdb) on md3
<7>smbd(2479): dirtied inode 46377 (account_policy.tdb) on md3
<7>kjournald(183): WRITE block 1196032 on md3
<7>md3_raid1(170): WRITE block 1975808 on sda3
<7>kjournald(183): WRITE block 5504 on md3
<7>kjournald(183): WRITE block 5512 on md3
<7>kjournald(183): WRITE block 5520 on md3
<7>kjournald(183): WRITE block 5528 on md3
<7>md3_raid1(170): WRITE block 1975808 on sda3
<7>pdflush(36): WRITE block 786944 on md3
<7>md3_raid1(170): WRITE block 1975808 on sda3
<7>pdflush(36): WRITE block 1048592 on md3
<7>pdflush(36): WRITE block 901696 on md3
<7>pdflush(36): WRITE block 901704 on md3
<7>pdflush(36): WRITE block 901712 on md3
<7>pdflush(36): WRITE block 852032 on md3
<7>pdflush(36): WRITE block 852352 on md3
<7>pdflush(36): WRITE block 901760 on md3
<7>pdflush(36): WRITE block 884808 on md3
<7>kjournald(183): WRITE block 5536 on md3
<7>md3_raid1(170): WRITE block 1975808 on sda3
<7>nmbd(613): dirtied inode 46394 (browse.dat.) on md3
<7>nmbd(613): dirtied inode 46395 (?) on md3
<7>kjournald(183): WRITE block 868560 on md3
<7>md3_raid1(170): WRITE block 1975808 on sda3
<7>kjournald(183): WRITE block 5544 on md3
<7>kjournald(183): WRITE block 5552 on md3
<7>kjournald(183): WRITE block 5560 on md3
<7>kjournald(183): WRITE block 5568 on md3
<7>kjournald(183): WRITE block 5576 on md3
<7>kjournald(183): WRITE block 5584 on md3
<7>kjournald(183): WRITE block 5592 on md3
<7>kjournald(183): WRITE block 5600 on md3
<7>md3_raid1(170): WRITE block 1975808 on sda3
<7>pdflush(37): WRITE block 0 on md3
<7>md3_raid1(170): WRITE block 1975808 on sda3
<7>pdflush(37): WRITE block 8 on md3
<7>pdflush(37): WRITE block 786928 on md3
<7>pdflush(37): WRITE block 786936 on md3
<7>pdflush(37): WRITE block 786944 on md3
<7>pdflush(37): WRITE block 950272 on md3
<7>kjournald(183): WRITE block 5608 on md3
<7>md3_raid1(170): WRITE block 1975808 on sda3

As a newbie, I found this site very usefull for lots of things !

I thought I might contribute a bit with the following:
-I improved the original fuel-gauge script, so that it can be used easilly with this awesome smart_spindown script.
basically, the new "fuel-gauge" script looks if the drives are spun up before trying to check things and thus creating potentially unwanted disk activity.
I wanted to do this because imho, fuel-gauge script is useful on the 2 disks edition using RAID-1, as it checks periodically the raid array integrity, and switches the leds to "degraded" if your array is broken. That way, it remembers you to force a reconstruction (I had one of the two disks of my WDMBWII gone wrong a few weeks ago)

If anyone's interested in my so-called "work", I might post it somewhere. But as I'm a newbie here, just tell me how I should proceed, and where I should post that: I don't want to disturb this place and its rules ! ;^)

Thanks very much for the prompt reply.

I have the MyBookWorld II, the 2TB edition with two drives and it's setup as RAID0. I tied to use the procedure explained in kyyhkynen's page to spin down the drive but I got stuck at step number 4 where it says the following:

4. Then you should tinker with the settings in the beginning of the "smart_spindown" (see comments in the script for details). At this time just set the name(s) of your disk(s).

Does anyone know what to set the disk names to please? (md3 (/var) and md4 (/shares/internal)?).

Your help is much appreciated,

Best regards,
Ash

Since your WD MyBook is hooked up on the lan at university it's not surprising you get a lot of activity - and the steps you've taken seem appropriate. If ~8 spinups per day is bothering you then set the WAITTIME & MAXTIME higher - or don't bother using smart_spindown at all - just leave it running. I'm not expecting spinning down the HD to lengthen the life of my WD MyBook, just to minimise the amount of electricity used. As long as you back it up occasionally & the drive last 5 years or so, then that seems a reasonable lifetime.

Cheers,
Paul

And yes it is true that mapping WD will cause unnecessary spinups sometimes (when you open my computer). But I listen often music with winamp from my WD and mapped drive is best solution for this AFAIK.

The-Bunker, I did not understand all of you advices, can you please clarify some?

- You said there is lot of smart_spindown restart activity, how can you see this from the log? In my case, smart_spindown script has been on for days, so it shouldn't be restarting anything.
- Also you adviced to put minimun time more low i.e 5mins. I have set it to 1 hour because usually when i'm listening music there is some pauses between me ghanging album or playlist or whatever, and this pause may be what ever between 1min to 1hour, so too small minimun wait time will cause spindowns.
-Is there lighttpd activity on my logs? I have not set its log to RAM, but I don't use lighttpd at all.
-what dows OUTPUTLEVEL do and what benefit is for setting it to false?
-what does local master = NO in SMB.conf?
- I have also done everything what kyyhkynen adviced in his tutorial. But havent disabled crontab. But then again, I don't use crons.

thanks in advance!

One thing I have changed to your script is to switch off the OUTPUTLEVEL - both to false.

I set my WAITTIME to 600 (10 mins) & MAXTIME to 1200 (20 mins) in smart_spindown script

Have you set local master = No in SMB.conf ?

I also disabled crontab & followed all the advice in the smart spindown tutorial for reducing disk access.
Finally - as recommended here, I don't have a mapped drive - just use a shortcut on my desktop to the PUBLIC share.

Hope you get things sorted - myspinups were averaging 16 a day & these mods have made a big difference.

Anyway, to answer your question - as I understand it the waittime is the minimum time before spindown - which in your case is 1 hour & would explain why it can spinup more often than you expect. Easiest way to test this is to make waittime something like 5 mins & leave max time as is - then see how long before it spins down.

fyi: I also added the lighttpd log files to ramdisk & that has also helped cut down the no of spinups.

Well, the result is really weird log, where spinup count can increase from 1 to 8 !! How the hell can this even be possible? Besides, I have se wait time 3600 sec and maxtime 10000 sec, and my max spindown time seems to be around 6 hours, so 10 spinups per day should be impossible!!

Please help me find where is the problem, I have 550 spinups and my WD is 2 months old :/

Here is My log where you can see this weird activity.

Here is my Smart Spindown script.

Since this version is newer than the one you referrence (7.7) I thought that it would not cause any issues.

However, when I execute the script (after setting the kernel parameters as instructed) the logging shows that both disks are spun down.
Polling is set for every 30 seconds, and I copied about 100MBs from the device to make sure that there was activity, but it still shows spun down.

Is this an issue with the optware hdparm? Or have I broken something?

Thanks.

I'm reasonably new to linux - so spent a couple days trying to work out why my MBWE was spinning up every 6 hours… after following all the tutorials, etc, worked out it was the default.script… then came across this post about using a static IP (in a thread I had read numerous times before - whoops).

So my question: does anyone know how to change how often busybox will run the default.script? I've had a bit of a look around, can find heaps of information on busybox & dhcp, but nothing related to a time period (6 hours).

I've set my MBWE to a static IP at the moment, and it's fixed the issue - though i prefer to use my router to assign static IP's, rather than the devices on the network.

Cheers!

I am not even close to being a linux expert, so my earlier question could be a bit off. I looked at the write log some more and it seems like the processes I mentioned always writes to the disk, regardless of what process initiated the write. Should I be looking at the processes generating lines like; "<7>tail(10976): dirtied inode 45 (temperature.log) on ram1" instead of these lines; "<7>pdflush(36): WRITE block 984 on ram1"?

Yes. The first line is the actual process issuing the write and the second is the cache management actually writing the stuff (issued on the first line) to disk.

Also note where the writing is done; in these lines data is written to the RAM disk (the ram1 in the end of the lines tells this) so they haven't spun the disk up. The lines you should check end with md1, md2, md3 or md4.

If you are going to mount your MBWE as a network drive, you'll need samba, which needs both of the processes smbd and nmdb running. I assume you have moved your samba logs and other files to your RAM disk.
Windows just sometimes connects to the network drives even if you're not actually accessing them in windows (like when windows starts up or when you open My Computer), thus causing the aforementioned processes to spin the disk up. In order to reduce these spin-ups, you can leave the "Reconnect at logon" checkbox unchecked when mapping the network drive in windows. By doing this, you'll have to manually connect to the drive by opening it in explorer before it can be used by other programs.

If so, the processes that spins up the disk in my last monitoring of the disk is: nmdb, sshd and smbd.

sshd should not be a problem if I´m not connected with ssh.
nmdb and smbd seems to be samba-related processes. Are both needed? I still want to be able to access the disk by mounting it as a network drive on my windows-machines. I did not access the disk in any other way than by ssh when these processes spun up the disk.

Thanx.

Thanx!

The only other line I can see (I'm no Linux expert) that probably needs changing is:
"use constant smbpasswd => '/var/private/smbpasswd';" change to "use constant smbpasswd => '/mnt/ramdisk/private/smbpasswd';".

Basically, changing only this line should be enough, if you have moved the smbpasswd file to the ram disk. I didn't find any other references to the files moved to the ram disk (but of course I could have missed some).

Been following most of the steps on your 'How To' on my 500GB MyBook World.

I stopped at the bit about

Note: if you plan to use the MBWE Web GUI to manipulate your users and shares after you change your samba file paths, you'll have to change the file locations in /usr/www/lib/nasCommon.pm file also. Otherwise, the Web GUI will be editing wrong files thus causing weird problems.

I don't know what to edit in nasCommon.pm. I want to keep using the Web GUI and have Samba use the RAM Disk like you suggest.

This line is already present and looks like it takes care of most of it:
"use constant smb_conf => '/var/oxsemi/smb.conf';"

The only other line I can see (I'm no Linux expert) that probably needs changing is:
"use constant smbpasswd => '/var/private/smbpasswd';" change to "use constant smbpasswd => '/mnt/ramdisk/private/smbpasswd';".

Can you tell me if that's right?

So far my drive still spins up a lot of the time. I think it's due to Samba.

Thanks

This is not true. Just modify the line in "inittab" to read:

::respawn:/sbin/syslogd -n -m 0 -O /mnt/ramdisk/system.log

And the log will now be written to the ramdrive rather than the harddisk.

Well I'll be damned.

I just assumed that if the busybox syslogd doesn't know how to read syslog.conf, it couldn't be done. Didn't realize that it has it's own custom switch for that…

Thanks for noting, will update the guide.

This is not true. Just modify the line in "inittab" to read:

::respawn:/sbin/syslogd -n -m 0 -O /mnt/ramdisk/system.log

And the log will now be written to the ramdrive rather than the harddisk.

Thanks,
sjf

Has anyone else noticed this?

What else have you added or changed on yours?

[root@MyBookWorld hdparm-7.7]# [root@MyBookWorld tmp]# cd src
[root@MyBookWorld src]# wget http://download.sourceforge.net/sourceforge/hdparm/hdparm-7.7.tar.gz
Connecting to download.sourceforge.net[150.65.7.130]:80
hdparm-7.7.tar.gz 100% |*********| 62530 ::— ETA
[root@MyBookWorld src]# tar -zxvf hdparm-7.7.tar.gz
hdparm-7.7/
hdparm-7.7/LICENSE.TXT
hdparm-7.7/Changelog
hdparm-7.7/kernel_patches/
hdparm-7.7/kernel_patches/01_libata_cmd_len_check.patch
hdparm-7.7/kernel_patches/02_libata_atapi_ata16.patch
hdparm-7.7/kernel_patches/README
hdparm-7.7/kernel_patches/03_libata_standby_spinup.patch
hdparm-7.7/hdparm.c
hdparm-7.7/hdparm.8
hdparm-7.7/README.acoustic
hdparm-7.7/hdparm.lsm
hdparm-7.7/identify.c
hdparm-7.7/TODO
hdparm-7.7/contrib/
hdparm-7.7/contrib/fix_standby.c
hdparm-7.7/contrib/ultrabayd
hdparm-7.7/contrib/README
hdparm-7.7/contrib/idectl
hdparm-7.7/contrib/fix_standby
hdparm-7.7/sgio.c
hdparm-7.7/debian/
hdparm-7.7/debian/hdparm.init
hdparm-7.7/debian/hdparm.conf
hdparm-7.7/Makefile
hdparm-7.7/hdparm-sysconfig
hdparm-7.7/hdparm.h
[root@MyBookWorld src]# cd hdparm-7.7
[root@MyBookWorld hdparm-7.7]# ./configure
bash: ./configure: No such file or directory
[root@MyBookWorld hdparm-7.7]#

I ran into this exact problem earlier today (only using vsftpd), and read the manual for busybox init, apparently if you start something with sysinit, then init will wait until that program exits before continuing, wheras using once spawns the process and carries on.

Since it's ultimately the job of init to clean up those zombie processes, they will never get sorted if you don't do this.

Also, if somebody with a single disk MBWE could test if the scripts actually work with it, it would be appreciated :)

I have MBWE with single disk 500 Gb and now trying your how-to - I'm ready to be your personal BETA tester :)

A 'freshman' question - can I see somehow how many times HDD has been spinned up and down? I want to let MyBook work for the long time

but another question for a linux beginner:
how do you enable the log temperature to make a html page like your to check the graph ?

can u make a tuto about that ?

i have try to enable myself but i'm not sure that have work:
i have edit the temperature script ( /usr/sbin/temperature_monitor )
and modify to:

1. Logging stuff

LOG_ENABLED=true
LOG_INTERVAL=5
#LOGGER=echo
LOGGER=logger

it's right ? if yes now how i build the html ?

One little thing I noticed is on the bottom line below (taken from your tutorial) it should be ntp.sh but a 'd' has slipped in the middle of it. Is fine everywhere else.

Whoops, thanks for noting that :)
Fixed.

All seems to be running fine so far, just testing it to see when/if/why it decides to spin-up now. Will let you know. :)

One little thing I noticed is on the bottom line below (taken from your tutorial) it should be ntp.sh but a 'd' has slipped in the middle of it. Is fine everywhere else.

Then copy the driftfile to the RAM disk and restart ntpd:

# cp /etc/ntp.drift /mnt/ramdisk
# /etc/init.d/ntpd.sh restart

Many thanks for the tutorial, a great help!!

Purchased a SATA hard drive enclosure. Booted my MacBook Pro using the System Rescue CD. Mounted Disk A using USB. Did an e2fsck -y /dev/sdb1 …. all the way to sbd4. It looked like sdb1 had some errors. Likely prevented booting.

Have spent many hours getting the spindown to work. Seems to be working for the most part… I can't believe how hot the drives were getting before!

I just went through the procedures, and on my last reboot, found that the system does not start up again. Ping, Web, ssh no longer work.

The procedure I followed is:
- SSH access http://martin.hinner.info/mybook/sshaccess.php
- Spin down http://kyyhkynen.net/stuff/mybook/#smartspindown
- WAITTIME=30
- followed up to steps 5. Received messages about disk being used, hence followed the disk usage reduction procedure.
- Alternative Temperature Monitoring script, done.
- Reducing Disk Usage, http://kyyhkynen.net/stuff/mybook/#reducediskusage
for this, I performed steps 1-6 (but did not reboot), then did 7, then rebooted.

After rebooting, the system does not start.
When I re-power the system, the hard-drives spin up, then there is some disk activity for about 10 seconds, then silence, and no activity. The light doesn't turn on (probably because I disabled it in one of the steps).

My switch keeps lists of DHCP requests, and the Worldbook does not appear to have asked for one.

It seems that restoring the system is not straightforward given that there is no human interface.
I also have some data there that I would like to recover.

Any ideas on how to get this running again?

I am thinking of hooking up the disk to an external hard drive enclosure to copy the data.

Any help appreciated.
thank you
Lukas

am I the only one to get an

HDIO_DRIVE_CMD(standby) failed: Invalid argument

error when the script is trying to supsend the drive?

Any ideas ho to fix that?

And one more thing in noticed, I can not run ./configure when I downloaded hdparm since there simply is no such script.

- Jens

P.S.: And beeing a noop on linux I would really apreciate a ramdisk howto :-)

The zombie processes were due to having mediatomb starting at boot time via a file in /etc/init.d/ , so finally it was nothing to do with the mods you suggested for spindown !

I should have spotted that fact earlier !!! Now to determine how to get mediatomb started automatically without these zombie processes ….

Cheers

local master = no

in smb.conf cause it kept writing some netbios stuff on a log

The only thing that kept spinning the disk up now (overnight) is ntpd writing to "ntp.drift.temp".

Any ideas?

local master = no

in smb.conf cause it kept writing some netbios stuff on a log

The only thing that kept spinning the disk up now (overnight) is ntpd writing to "ntp.drift.temp".

Anyideas?

I have Windows comp and old linux laptop (thinkpad 600e - does not look promising).
Just thinking about using Ubuntu Live CD on the desktop - hope it does support SATA drives

After rebooting the drive I can't get in to the drive anymore.
Drive is powering down correctly by power button, which LEDs dimming.