On 11/23/2010 04:32 PM, Lennart Poettering wrote:
On Tue, 23.11.10 16:12, Doug Ledford (dledford(a)redhat.com) wrote:
> On 11/23/2010 03:48 PM, Lennart Poettering wrote:
>> Heya!
>>
>> I hereby want to let everybody know that in the next days I will turn on
>> /var/run and /var/lock on tmpfs on Rawhide/F15. This is in accordance
>> with the following accepted F15 feature:
>>
>>
https://fedoraproject.org/wiki/Features/var-run-tmpfs
>
> Will the tmpfs mounts be available in the initramfs, or only on the
> running system?
Since /var/run is a subdir of /var which might be separate file system
it is difficult mounting /var/run before /var. That means that it won't
be available in the intird.
(Yes, one can do stuff with show-through mount hierachies, that would
allow replacing /var later on, but I am not a fan of such hackery.)
Hackery is in the eye of the beholder.
Also note that by now it's somewhat standard that code that needs
to be
run as part of early boot creates a subdir in /dev, such as /dev/.udev
or /dev/.systemd. Not super-pretty, but I guess it's too late to
complain about that.
Those places all exist *because* no one took the time to create an
initrd managed writable /var/run or /var/lock. Using their existence to
justify continuing down a path that places files where they don't belong
is faulty logic. I took a *major* beating by the upstream mdadm
maintainer over the fact that we are putting files in /dev/ that don't
belong there. And he's right, we *shouldn't* be putting those files
there. Continuing a band aid hack because someone did it initially is
not the right course of action.
Ideally the FHS would have never specified that /var/run and
/var/lock
would lie beneath /var, but I guess that's too late now.
One failed specification isn't really a good reason to justify creating
a de facto second failed specification.
--
Doug Ledford <dledford(a)redhat.com>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband