Re: /run vs /var/run (was: Please test new sysvinit)
On Mon, 19 Dec 2005, Steve Langasek wrote:
> > > by constraining the actual *implementation* of /run (barring ugly
> > > hacking of the init scripts), you've made the system less suitable
> > > for a third use case:
> > >
> > > - memory is at a premium, disk is not
Then IMHO Debian is NOT the appropriate system to run on that box. Get a non
glibc-based one that also likes to pass -Os to gcc and compiles the kernel
> > Tmpfs memory can be swapped out, so is this even a hypothetical problem?
> Maybe it isn't on Linux. I wasn't aware tmpfs could be swapped out.
All VM-based filesystems in the BSDs, Linux and Solaris swap out just fine,
and they always have done so AFAIK. In fact, other than the filesystems for
on-chip disks (flash or eeproms), and stuff like procfs and sysfs that
aren't really there anyway, I have never heard of non-swappable in-memory
> That still leaves the question of just which features we want to require
> from our non-Linux kernels for basic operation, I guess.
Those are: Solaris, *BSD and The Hurd. Solaris and all of the BSDs can do
VM-based filesystems that are nearly identical to tmpfs. I don't know about
> Sounds to me like this will play havoc with idempotence of init scripts;
> anyway, why would "mount /run and clean it" be anything less than an atomic
> operation from the viewpoint of other init scripts?
There's no reason, if we don't break the init scripts in some misguided try
to run them in parallel without proper barriers/dependencies :-)
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot