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

[Gerardo Exequiel Pozzi]

On 11/18/2011 12:03 AM, Dave Reisner wrote:
> 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'.
I know, but again, rootfs is the *HEAD* of vfsmount.

[ramfs /]# mkdir a b
[ramfs /]# mount --bind a b
mount: mounting a on b failed: Invalid argument
[ramfs /]# mkdir coco
[ramfs /]# mount -t tmpfs coco coco
[ramfs /]# cd coco/
[ramfs /coco]# mkdir a b
[ramfs /coco]# mount --bind a b
[ramfs /coco]#


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