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

[Dave Reisner]

On Thu, Nov 17, 2011 at 11:48:27PM -0300, Gerardo Exequiel Pozzi wrote:
> On 11/17/2011 11:03 PM, Dave Reisner 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.
> I did nothing about chroot. misreading?

I assumed you were when you mentioned files "under" a mount.

> In shell terms
> 
> Point1:
> * we are on rootfs (special case of tmpfs/ramfs) the HEAD of vfsmount *
> 
> mkdir /a
> mkdir /b
> mount --bind /a /b <- this will not work, you can not reference a

No, that absolutely _will_ work. Binding arbitrary directories is
totally kosher, and I do it fairly frequently. You can even bind mount
files, i.e.

  echo blah > foo
  touch bar
  mount -B foo bar

When you 'cat bar' it will have the same contents as 'foo'.

> unnamed mountpoint. (for the same reason that you can not pivot_root
> and must use switch_root)
> 
> 
> Point2:
> * we are on any normal mount point *
> 
> mkdir -p src/{a,b} dst
> touch src/a/s src/b/t
> mount --bind src/b src/a
> cp -ax src dst
> cp: will not create hard link `dst/src/a' to directory `dst/src/b'
> 

Seems like its working as intended. There must be some inode comparison
going on in addition to the devno check.

> >  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 /
> Sure, but you can not access files under lower mountpoint using the
> same path. Or I am misunderstood something?
> 

What's under / is unimportant. We just (have to) assume that its the
real root.

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/91b516ed/attachment.asc>