Re: /dev on a ram disk
In article <[🔎] 19971208140811.56163@kite>, Joey Hess <joey@kitenet.net> 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
>by hand).
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.
--
Charles Briscoe-Smith
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
debian-user-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-user-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: