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

[Gerardo Exequiel Pozzi]

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?

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 
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'


>   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?


>
>> 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


-- 
Gerardo Exequiel Pozzi
\cos^2\alpha + \sin^2\alpha = 1