[arch-projects] [mkinitcpio PATCH 1/3] /run/initramfs: copy the whole ramfs

[Tom Gundersen]

On Fri, Nov 18, 2011 at 1:03 PM, Dave Reisner <d at falconindy.com> wrote:
> On Thu, Nov 17, 2011 at 10:51:37PM -0300, Gerardo Exequiel Pozzi wrote:
>> On 11/17/2011 10:21 PM, Dave Reisner wrote:
>> >On Fri, Nov 18, 2011 at 11:42:43AM +1100, Tom Gundersen wrote:
>> >>On Fri, Nov 18, 2011 at 5:23 AM, Thomas Bächler<thomas at archlinux.org>  wrote:
>> >>>Am 17.11.2011 18:07, schrieb Tom Gundersen:
>> >>>>I see two potential issues: boot speed and memory use. Moving stuff
>> >>>>around in memory should be pretty much instantaneous, and the memory
>> >>>>(a couple of MB) will be swapped out quick enough so it shouldn't make
>> >>>>a difference.
>> >>>>
>> >>>>I'd be happy to write a new patch where this is optional, but I don't
>> >>>>think we should optimize for stuff unless we know it is a measurable
>> >>>>problem.
>> >>>Depending on what's in there, it could be big. For example, I once wrote
>> >>>a hook that extracted a tarfile that was stored inside initramfs (that
>> >>>tarfile was the whole root filesystem IIRC).
>> >>That's something to take into consideration. I think it would be best
>> >>if we were able to optimize the cases that need it by adding some
>> >>exceptions to the copying, but still keep the bits needed for
>> >>shutdown++, rather than disabling it altogether. Having huge
>> >>initramfs' being a corner case, any workaround should of course be
>> >>unintrusive (if that is not possible then I agree on just allowing
>> >>this stuff to be switched off).
>> >>
>> >>[untested: would bindmounting a directory (like say /lib/modules) to
>> >>itself exclude it from "cp -ax"?]
>> >No, it won't. Generally, detection of crossing onto another mount is
>> >done by comparing the devno of '.' to the devno of '..'. Bind mounts
>> >aren't special in this regard -- they'll just expose the underlying
>> >physical mount.
>> Mmm no, you can not access to files in underliying mount from such path.
>> Anyway the rootfs is the HEAD of vfsmount, so you can not
>> bind/move/pivot. :P
>> But supose that you can do a bindmount... -a is used that implies
>> -d, that implies --preserve=links, in that case cp will fails
>> because will try to create a link to directory. ;)
>
> No, this has nothing to do with chrooting. The point is that if you're
> walking through a directory structure for an operation that's required
> to stay on a single filesystem, you're stat'ing every directory before
> descending into it (my example was actually backwards). Written in
> (probably nonworking) shell..
>
> walk() {
>  local pwd_dev dir_dev
>
>  pwd_dev=$(stat -c %d "$1")
>
>  for f in *; do
>    if [[ -d $f ]]; then
>      dir_dev=$(stat -c "$1/$f")
>      if (( pwd_dev != dir_dev )); then
>        # this is a mountpoint, skip it
>        continue
>      fi
>      walk "$f"
>    else
>      callback "$f"
>    fi
>  done
> }
>
> walk /
>
>>
>> Why no just copy the needed files? Yes needs more steps...
>
> Because I don't want to have to calculate what's needed for teardown on
> an encrypted LVM root device. Make it optional, and everything is
> copasetic.

Thanks for the explanations Dave and Gerardo.

I agree that it would be best to just copy everything, which would not
require us to do anything fancy.

Still not sold on making it optional though. At least wait until
someone can point to a use-case and some numbers that shows a real
problem. If the initramfs is sufficiently huge, the time taken to copy
it to /run would obviously be measurable. However, the time taken to
extract the initramfs in the first place would probably dwarf this
number.

If we start making things optional we'd have something like this:

copying /run/initramfs is required by "shutdown" and "shutdown" is
required by "usr".

But all users who have a separate /usr must use the "usr" hook, and
all users really should use the "shutdown" hook. So unless we find a
case where including a hook causes some sort of real downside I'd say
just make it unconditional, and thereby reduce the number of
configurations we'd have to test.

>From the point of view of initscripts it would be very nice to know
that /usr is always mounted, and if the rootfs is on lvm or something
like that it will always be torn down properly, without worrying about
users possibly disabling these hooks in mkinitcpio.

Just my two cents.

-t