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

[Dave Reisner]

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.

d
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/arch-projects/attachments/20111117/b9ac53bb/attachment.asc>