Ccing intramfs since it could be of interest
background:
Doug's patch moves mdmon pid file and socket from /var/run to /dev
to preserve them after pivot-root
Rationale is mdmon gets started in initramfs when imsm or ddf arrays are
activated.
Neil does not like the proposed solution
On Mon, Feb 01, 2010 at 08:08:54PM -0800, Michael Evans wrote:
On Mon, Feb 1, 2010 at 2:42 PM, Bill Davidsen <davidsen@xxxxxxx> wrote:
Doug Ledford wrote:
On 02/01/2010 03:32 PM, Bill Davidsen wrote:
Doug Ledford wrote:
On 01/18/2010 05:09 PM, Neil Brown wrote:
I understand there is a problem here, but I don't like this approach
to a
solution. I'll give it more though when I get home from LCA2010 and
see
what I can come up with.
Feel free to come up with something different. But, if your solution
involves maintaining an additional read/write mount area in deference to
a long dead unix tradition, I'm just going to shake my head and patch
your solution away to something sane.
I don't understand you argument here. Not the one where you say you're
going to ignore Neil and do what you want because you can, I understand
that, but the "additional read/write mount area" part, isn't /var/run
r/w on all systems now? Could you clarify why this is "additional" here?
It's not necessarily read/write in the initrd time frame, and putting
the mdadm files there means it would have to be. We didn't make these
changes because we wanted to, we made them because using mdadm raid
arrays for the root filesystem combined with incremental assembly or
with imsm raid devices was broken otherwise.
Do understand that my disquiet related to this isn't because you put a
non-device in /dev, it's that you
didn't put a process PID in /var/run. And frankly, once you let (force) one
group of threads to be somewhere
else, other services will want their PIDs some other place, and anyone
maintaining an application
which presents information on what's running will need to know where that
information.
In other words, it's not where you put it, it's where you *didn't* put it,
that seems to be an
invitation to put stuff just anywhere. Neil argues that they are not
devices, I argue that
they are PIDs. It's not as though it were a huge effort to move it after
pivot root, it's a little code
or script and in space which will be released.
--
Bill Davidsen <davidsen@xxxxxxx>
"We can't solve today's problems by using the same thinking we
used in creating them." - Einstein
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Thank you for stating your concern; I think knowing that a very
plausible solution is obvious.
# at initrd/initramfs creation time
ln -s /dev/.run /var/run
#initrd/initramfs script
mkdir /dev/.run
The usual area becomes a symlink to a memory disk .Most systems have
ample memory to support a few extra tiny files there. Cleanup on
reboot is automatic. Any systems that are memory constrained probably
already either have a drive they could swap this data out to, or would
rather save the writes from reaching flash media anyway.
this could be interesting, but then you have to move things back to
/var/run after pivot root, and we cannot move a socket.
still if it would suit both parties we could
- keep the mdmon pid file in /var/run and use initramfs magik to preserve
those pid files, this could become a standard solution when the next
daemon arrives that needs to start from initramfs.
- put the socket in /dev/md, and i defy anyone to say sockets do not belong
in /dev, bringing forth the syslog daemon as a witness.
Regards,
L.
--
Luca Berra -- bluca@xxxxxxxxxx
Communication Media & Services S.r.l.
/"\
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
