dledford at redhat.com
Thu Feb 4 18:13:44 UTC 2010
On 02/04/2010 05:09 AM, Harald Hoyer wrote:
> I would like to follow debian and add a tmpfs to /lib/init/rw , which would
> serve as a transition from initramfs to real root for files from daemons, which
> need to transition from initramfs, like mdmon, dmeventd, rpc.statd, etc.
> FYI, /var is not an option, because it can be on a seperate partition.
> Currently we use /dev/.initramfs, which is just a workaround, because /dev is
> already available.
> What do you think?
I think it's silly to create a second rw tmpfs location. I think this
for two reasons: 1) if you aren't going to move the stuff out of this
temporary location to where it belongs after the filesystems are brought
up, then this location becomes a catch all that multiple things might
need to end up adding to their search path (eg., mdmon would create pid
files here, if those pid files aren't moved or otherwise made accessible
under /var/run later, then subsequent attempts to use things like status
mdmon from an initscript would need to be taught about the new pid file
locations which is something we want to avoid like the plague) and 2) if
you *are* going to do the right thing and move things to their right
locations later, then whether you use /lib/init/rw or /lib/init/state or
/dev/crap_we_wont_leave_here_under_penalty_of_death makes no difference,
it's going to be emptied and deleted eventually anyway, however, adding
a second mount point adds complexity to the early boot process which is
something you always want to be as simple and failproof as possible, so
creating a new namespace for the sake of anal retentiveness about naming
is in fact counter productive and the wrong thing to do. As such, I say
suck it up and deal with /dev/.initramfs.
Doug Ledford <dledford at redhat.com>
GPG KeyID: CFBFF194
Infiniband specific RPMs available at
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100204/4229a07f/attachment.bin
More information about the devel