Re: /dev on a ram disk
- To: firstname.lastname@example.org
- Subject: Re: /dev on a ram disk
- From: email@example.com (Charles Briscoe-Smith)
- Date: 11 Dec 1997 14:54:14 -0000
- Message-id: <firstname.lastname@example.org>
- References: <19971208000506.12835@kite> <19971208140811.56163@kite>
In article <19971208140811.56163@kite>, Joey Hess <email@example.com> wrote:
>Maybe you're still getting disk accesses because of the update daemon? You
>could try killing it to check. (of course, then you have to sync your disk
As far as I can tell, the update daemon in the more recent kernels (all
of the 2.0 series, I think) is clever enough to not write out the super
block if there's nothing else to be written to disk. So update won't
touch the disk unless something's been written (or an atime updated)...
My box has successfully been left idle for hours with the disk spun down.
update was still running, as well as syslogd/klogd, kerneld, inetd, gpm,
apache and probably others. IIRC atd was running, too. smail starts the
disk up every 20 minutes to check the local mail queues. cron starts
the disk up every hour to rescan the crontabs (why that should be, I
don't know). I rebuilt cron with a max sleep time of a day instead of
an hour, which worked well... With virtual-dev installed, I can even
leave an idle X session up without keeping the disk spinning.
virtual-dev is still experimental, because, on my machine at least, it
interacts badly with sysvinit, making shutdown hang. Has anyone else
had this problem? When virtual-dev goes into unstable, it'll be called
devices-in-ram instead, BTW. virtual-dev was a supremely bad choice of
name on my part.
White pages entry, with PGP key: <URL:http://alethea.ukc.ac.uk/wp?95cpb4>
PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
Trouble? e-mail to firstname.lastname@example.org .