On 02/08/2010 04:38 PM, Neil Brown 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?
I second the idea, but I hate the name run. Mainly because it's not
really descriptive to the issue at hand. I mean, everything needs to
run, the part that's different about all of this is that it needs to run
*pre-root-filesystem-available*.
If we were to stick with unix tradition of being short and cryptic (but
make sense when explained), then /ptmp -> /dev/ptmp might work with the
explanation being that it's a pre-init temporary file area (or
pre-root-filesystem temporary file area).
Of course, the /ptmp -> /dev/ptmp would only be if we are using the dev
filesystem for simplicity's sake. However, as someone else mentioned,
realistically if we want this to be accepted, it should not be dependent
on udev and a tmpfs based dev directory, it should stand on its own.
Meaning that it *should* be its own minor tmpfs filesystem mounted at
/ptmp. But maybe that's something to work toward versus a first step.
--
Doug Ledford <dledford@xxxxxxxxxx>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
Attachment:
signature.asc
Description: OpenPGP digital signature
