Re: [[Patch mdadm] 2/5] Move the files mdmon opens into /dev/ to support handoff after pivotroot

[Luca Berra <bluca@comedia.it>]

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@tmr.com> 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@tmr.com>
>>  "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@vger.kernel.org
>> 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@comedia.it
         Communication Media & Services S.r.l.
  /"\
  \ /     ASCII RIBBON CAMPAIGN
   X        AGAINST HTML MAIL
  / \
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html