On Mon, Feb 8, 2010 at 1:38 PM, Neil Brown <neilb@xxxxxxx> wrote:
> On Mon, 08 Feb 2010 10:32:53 -0500
> Doug Ledford <dledford@xxxxxxxxxx> wrote:
>
>> On 02/06/2010 04:07 PM, Dan Williams wrote:
>>
>> > This comment makes me see Neil's argument in a different light,
>> > (hopefully I am not mischaracterizing it), but essentially we are
>> > waiting for the standards to catch up with this new class of program.
>> > FUSE, CUSE, and mdmon belong to a class of programs that move
>> > traditionally exclusive kernel space functionality to userspace.
>> > Debian's /lib/init/rw looks to be a response to this grey area of the
>> > standards (not that I have any familiarity with the LSB).
>>
>> So if we want to argue that the standards are simply behind the times,
>> and we need to do something that makes sense regardless of the
>> standards, then I don't think anything in /dev or /lib makes sense. The
>> files that need to be created pre-rw-root are varied in their type and
>> purpose between different things. What we really need is simply an
>> early boot /tmp area. So, why not make a top level directory that
>> clearly delineates this nature? Something like /pre-init or /early-tmp
>> or whatever? Or possibly /tmp/pre-boot or /tmp/pre-init or
>> /tmp/pre-pivot-root (the pre-pivot-root naming is awfully linux
>> specific, so maybe /tmp/pre-init or /tmp/pre-boot would be better for
>> possible standards acceptance later)? I was thinking that mdmon's files
>> would be stuck there, but then I remembered that we are doing option #3
>> for mdmon, restarting after the system is up and running, so only the
>> mdmon instances from the initramfs would put their files there, the
>> final ones would be on the real /var/run area. So, since as far as I
>> know the mdmon .sock files were the only pre-boot files that couldn't be
>> moved later (but effectively get moved by restarting mdmon after r/w
>> /var/run), any and all files in /tmp/pre-pivot-root should be removed
>> once the system is up and running, and quite possibly the filesystem
>> could be entirely done away with. At least then the naming would be to
>> Neil's satisfaction I think, and mine. And personally, when the
>> standards are simply behind the times, I have no problem blazing ahead
>> and letting them catch up when they get off their asses.
>>
>>
>
> That's the spirit!!!
> Let's figure out what we really want/need, and just do it.
>
> Following my recent discovery that mdmon prevents /var from being unmounted
> at shutdown, I wonder if we really want something generic that persists from
> very early boot to very late shutdown, rather than just the early-boot part.
> So something like /var/run, but not dependent on /var and guaranteed to be
> in-memory (or swap) and created very early by initramfs.
>
> /run
> ???
> Trivial implementation for most distros would be to make it a symlink
> to /dev/run.
>
> I would prefer a name a little more descriptive than "/run" - something that
> reflects the idea that it is particularly for early-boot or late-shutdown -
> but nothing comes to mind.
>
> I could probably actually live with "/dev/run" as the permanent home for the
> mdmon files: /dev/run/mdmon/*.{sock,pid}
> It addresses most of the issues I had with the original suggestion (hidden
> files, non-generic approach) so the "cons" are weaker. And I now understand
> the "pros" better (races with cleaning /var/run, issues with unmounting /var
> etc).
>
> Anyone second the motion?
>
> NeilBrown
> --
> 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
>
What about systems that have only devices known at compile/create time
and thus might be created with a fully static /dev for extra
simplicity. We should not simply expect that /dev is read-write as a
system requirement. This is one reason why my previous solutions
suggested using a known area and symlinking in an implementation
defined way that mdadm/mdmon didn't need to know about.
Maybe a good name for it is '/state' as in system state information.
It would be reasonable to expect it to be a ram/swap backed filesystem
for SMALL files to exist as a user-space state area for various
daemons and such.
However any information in there which is also potentially useful to
in-kernel code should probably be re-located to an entry exposed via
sysfs.
--
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
