Re: Moving /var/run to a tmpfs?
On Sat September 16 2006 16:56, Petter Reinholdtsen wrote:
> [Steve Langasek]
> > However, that's not the same thing as saying it's ok for sysvinit
> > to *make* /var/run a tmpfs on the admin's behalf. I think it's
> > pretty clear that this violates the letter of the FHS, and such a
> > change needs to be considered carefully.
> I fail to see how it violates the letter of the FHS. It is as far as
> I can see unspecified what kind of file systems will be used, and
> also if directories will persist across boots.
> The reason I believe it is important to have some writable file
> system available at the very beginning of the boot is that there are
> programs running when kernel modules are loaded by udev that need a
> place to store state information. At the moment, there is no
> location to do that, and strange things can happen when the coldplug
> events happen early in the boot. To fix it, some tmpfs area need to
> be mounted in mountkernfs.sh. This issue has been discussed here on
> the list a few months ago, without any conclusion being reached. I
> do not want us to release etch with a boot system unable to handle
> detected hardware properly, so I decided to fix this now. Also, it
> is useful to make it easier to set up stateless workstations using
> Debian (aka diskless machines ala LTSP), and storing state
> information in a RAM file system make this a lot easier.
Sounds fine, if one has enough RAM to spare.
How big can /var/run get? Could such a change limit the usefulness of
low mem systems? Is it feasible to create a tmpfs based /var/run during
boot then move its contents to a disk based /var/run (if that is the
admin's the preference) when /var becomes available?