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

Dave Reisner d at falconindy.com
Thu Nov 17 20:21:20 EST 2011


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.

> > Other than that, people WILL complain.
> 
> Undoubtedly. They always do.
> 

Always.

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/384a731f/attachment.asc>


More information about the arch-projects mailing list