silencing a 2.5" drive under debian linux

[rtsai]

any luck with this?

I'd have to roll back to ext2 to try this out, so I'm not eager to dive in ...

EDIT: reverting ext3->ext2 is not a big deal; you can actually basically just change the fstype in your /etc/fstab and remount. Lots of google references to this.

[grandpa_boris]

any luck with this?

I'd have to roll back to ext2 to try this out, so I'm not eager to dive in ...

at this point, i wouldn't touch ext3 at all if i have any alternatives. i ended up having one or two bad sectors on the disk and after several failed attempts to recover the root fs, ext3's fsck had completely destroyed it.

i have one thing to add to the list of things mentioned in the article quoted above: dhcp logs. i think those were the only ones that i didn't move and in retrospect i think this is what was waking up the disk. but most importantly, i believe the best approach is to avoid that nasty little seagate screamer and buy a samsung spinpoint that got such great reviews instead.

since ext3 had eaten my system and i didn't yet have time to replace the drive, i've been experimenting with stand-alone linuxes, booted from CDROM (knoppix and its variants) and even from floppy (LEAF bering, which required retrofitting a floppy drive into my machine! ). these haven't been terribly successful efforts yet mostly because i haven't had the time to invest into making them work, but they offer an interesting and reasonably priced alternative to using flash memory as a boot device. however, with the price of older technology CF cards dropping below $60 for 256MB, it may be an option i will explore as well.

[rtsai]

I've gotten this working on my system: Dell Optiplex GX-1 (1999) with BIOS A10, P2-450MHz, Samsung SP1614N, debian testing, ext3 filesystems, kernel-image-2.6.7-1-686

I fixed /etc/fstab to mount all partitions with noatime.

I prepended all my /etc/syslog.conf entries with "-" (no sync), fixed up my /etc/hdparm.conf with "spindown_time = 0", fixed /etc/init.d/sysklogd to run with "-m 0" (don't log "--MARK--" every 20 minutes), and added a "disable stats" to my /etc/ntp.conf (so that it doesn't write stuff to /var/log/ntpstats all the time).

Then I installed noflushd with default settings ("-m 5") in /etc/default/noflushd .

After restarting all the affected daemons and remounting all my filesystems, my HD indeed spins down and stays spun down until I do something to it (like run hddtemp to see its temperature).

Other stuff that may or may not be relevant; these were already present in my system before I attempted this spindown exercise:

I disabled ACPI in my BIOS. I run apmd (without it, I still have to manually hit the power switch after issuing "halt").

One note is that you may be tempted to run noflushd with "-v" flag (log spindown/spinup activities). This doesn't work because after your drive spins down, it will immediate spin back up to log the fact that it was spun down . You just have not use this flag and be patient, wait for your drive to spin down, and sit around some more to verify that it doesn't spin back up again.

Also, "hdparm -y /dev/hda" doesn't work for me; the drive spins down and then immediately spins back up again (hence the spindown_time=0 in /etc/hdparm.conf, noted above).

The services that this box provides: DHCP server, DNS server. All DHCP addresses are statically assigned with a lease time of -1, so at least that much is different from your setup. This will eventually also be an rsync server (home backup) which is fine for my purposes; I just want the box to spin down during the day and at night when it is truly idle.

Tons of stuff on google related to ext3, noflushd, and linux-on-laptop (motivation on these sites is usually to conserve battery life, but has good quiet side-effects for us as well).

[Inexplicable]

I prepended all my /etc/syslog.conf entries with "-" (no sync)

That shouldn't help much. The new log entries should still get flushed to disk all the same, albeit with a slight delay. Does noflushd do some magic to delay asynchronous block writes if the disk is spun down, or what? At least frequent logging might prevent the disk from spinning down in the first place. I basically suppressed all non-essential and periodic logging to achieve the same effect.

One note is that you may be tempted to run noflushd with "-v" flag (log spindown/spinup activities). This doesn't work because after your drive spins down, it will immediate spin back up to log the fact that it was spun down .

Direct the messages to the console. You don't have to save them to a file.

Also, "hdparm -y /dev/hda" doesn't work for me; the drive spins down and then immediately spins back up again (hence the spindown_time=0 in /etc/hdparm.conf, noted above).

You might have process accounting enabled. Try this:

Code: Select all

apt-get --purge remove acct

I'm still having trouble with the DHCP client. I've done everything I can think of but it still manages to spin up the disk whenever it renews the lease. DHCP logging is disabled, the lease files are stored on tmpfs and I've made sure resolv.conf is only written if the DNS configuration changes. Any ideas?

[rtsai]

I prepended all my /etc/syslog.conf entries with "-" (no sync)

That shouldn't help much. The new log entries should still get flushed to disk all the same, albeit with a slight delay. Does noflushd do some magic to delay asynchronous block writes if the disk is spun down, or what?

My understanding of reading the (slightly outdated) noflushd webpage is that *all* writes are deferred in RAM until RAM is needed for non-diskio-related purposes (e.g., real work). Writes are committed when a read that cannot be satisfied from in-memory cache requires that the disk be spun up anyway. A quick perusal of a sampling of web postings implies that this write deferral can be quite substantial.

If I issue a manual "sync" at the prompt, my disk immediately spins up. So at least that much supports the syslog-configuration steps. But as you say, this makes a minimal difference in my setup (though for a different reason) -- I have many many many packages removed from my system, so most of the syslog entries are irrelevant anyway.

One note is that you may be tempted to run noflushd with "-v" flag (log spindown/spinup activities). This doesn't work because after your drive spins down, it will immediate spin back up to log the fact that it was spun down .

Direct the messages to the console. You don't have to save them to a file.

How do I do that? The "-v" flag didn't offer me any options; or are you saying I can do this via syslog.conf? The machine is basically headless, but I do have a spare monitor that I leave plugged in for emergencies (and to satisfy my curiousity that noflushd is actually working ).

Also, "hdparm -y /dev/hda" doesn't work for me; the drive spins down and then immediately spins back up again (hence the spindown_time=0 in /etc/hdparm.conf, noted above).

You might have process accounting enabled. Try this:

Code: Select all

apt-get --purge remove acct

Thanks, but I actually don't have the "acct" package installed. Perhaps another package is providing the same services? I'm actually relatively new to debian (and loving it), so I haven't quite learned all the new package names yet. In any case, I don't care about this that much anymore now that noflushd appears to be working for me.

I'm still having trouble with the DHCP client. I've done everything I can think of but it still manages to spin up the disk whenever it renews the lease. DHCP logging is disabled, the lease files are stored on tmpfs and I've made sure resolv.conf is only written if the DNS configuration changes. Any ideas?

Which DHCP client are you using? Are you using the resolvconf package? If your DHCP client does anything like ifdown/ifup, then that would cause resolv.conf to be rewritten. And how often is your DHCP client renewing its lease? Can you increase the requested lease to some higher value more acceptable to you? At least for my purposes, spinning up my disks like once an hour is perfectly acceptable. I only really care about night time silence for this system. My system is the DHCP server for my home network, so it isn't running a DHCP client . Maybe you can play around with different DHCP clients (pump, dhcp, dhcp3, dhclient come to mind); they all behave in different ways, and maybe one of them is different enough to not spin up your disks.

Do you have swap? My system has no swap partition. I have 256MB RAM and it doesn't feel tight at all, but this system really isn't doing much besides Folding and being an rsync server for once-every-few-days backups.

I've read on some web pages that gconfd and exim are other logging culprits, and those are also some commonly-installed packages, maybe you have those too?

[Inexplicable]

My understanding of reading the (slightly outdated) noflushd webpage is that *all* writes are deferred in RAM until RAM is needed for non-diskio-related purposes (e.g., real work). Writes are committed when a read that cannot be satisfied from in-memory cache requires that the disk be spun up anyway. A quick perusal of a sampling of web postings implies that this write deferral can be quite substantial.

Hmm. That's certainly effective but I'm not sure I'd be quite comfortable with that on my main computer. My preference would be to use a journaling filesystem and to place the journal on a non-volatile ram disk, coupled with some noflushd style magic to delay the commit from journal to disk.

How do I do that? The "-v" flag didn't offer me any options; or are you saying I can do this via syslog.conf?

Exactly. Syslog is pretty versatile. Just use /dev/console or /dev/ttyX as the log file. I'm not sure which logging target it uses but it's probably something along the lines of "daemon.info".

Thanks, but I actually don't have the "acct" package installed. Perhaps another package is providing the same services? I'm actually relatively new to debian (and loving it), so I haven't quite learned all the new package names yet. In any case, I don't care about this that much anymore now that noflushd appears to be working for me.

Ok. For me it was the process accounting storing statistics after each command. Might be something else. You can use find with the -cmin option to find out recently written files. That might tell you what's happening.

Which DHCP client are you using?

Code: Select all

# dpkg -l dhcp-client
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name               Version            Description
+++-==================-==================-====================================================
ii  dhcp-client        2.0pl5-19          DHCP Client

I've tried version 3.0 as well, although it seems to be derived from the same source. Actually, an older 2.0 used to work just fine. I lost it when I tried out version 3.0 for kicks.

Are you using the resolvconf package? If your DHCP client does anything like ifdown/ifup, then that would cause resolv.conf to be rewritten.

No, resolvconf writes temporary files all over /etc. I've written my own /sbin/resolvconf script that does exactly what I want.

And how often is your DHCP client renewing its lease? Can you increase the requested lease to some higher value more acceptable to you?

No such luck, the lease time is set by my ISP. The lease gets renewed every 2.5 hours.

At least for my purposes, spinning up my disks like once an hour is perfectly acceptable.

I'm aiming at once per day, in the wee hours of the night when I'm fast asleep. This is a box I don't normally use interactively and the drive is pretty loud. Besides, constantly spinning the drive up and down can shorten it's lifetime considerably.

Anyway, the problem is pretty subtle. According to timestamps, none of the files on the root fs actually get modified. I'd try noflushd but, as has been mentioned earlier, it doesn't like journaling filesystems. Fast reboot is important to me, because this particular box is my gateway to the outside world.

Oh, I have no swap either. None of my machines do.

Well, no pain, no gain. I'll figure it out eventually.

[grandpa_boris]

Well, no pain, no gain. I'll figure it out eventually.

if you do, please post it!

[Inexplicable]

Well, no pain, no gain. I'll figure it out eventually.

if you do, please post it!

Well, I did, and boy do I feel stupid. Turns out it was syslog after all. Here it is, the ages old entry for piping log messages to xconsole:

Code: Select all

daemon.*;mail.*;\
       news.crit;news.err;news.notice;\
       *.=debug;*.=info;\
       *.=notice;*.=warn       |/dev/xconsole

Commented it out and now it works. Somehow I thought (reasonably, in my opinion) that writing to a fifo should not spin up the disk. Wrong. Turns out the fifo inode is marked dirty. Sigh.

[grandpa_boris]

reverting ext3->ext2 is not a big deal; you can actually basically just change the fstype in your /etc/fstab and remount. Lots of google references to this.

just be sure that your ext3 fs is clean and there is nothing in the log. i'd probably do fsck of the ext3 fs, then change its type to ext2 before mounting it.

[grandpa_boris]

Well, I did, and boy do I feel stupid. Turns out it was syslog after all. Here it is, the ages old entry for piping log messages to xconsole:

interesting. i didn't install and configure X on my debian system, but it doesn't mean it didn't have that same directive. great detective work!

[rtsai]

Heh. I just found a similar sneaky one. I've been running Folding@Home, which innocuously generates logs rather infrequently (once every 20 minutes on my current work unit). I took care of that by writing a "start" script to copy everything over and chdir to a tmpfs before starting, and a "stop" script to copy everything back to disk.

[koody]

It would be very nice if the wealth of information in this thread could be migrated here: http://wiki.linuxquestions.org/wiki/Quieting_linux

Please add this very useful Linux silencing info here

I'll definietly use the information here, but it's always difficult to remember exactly what to search for, and the articles will slowly sink in to oblivion.

Thanks.