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 5:23 AM, Thomas Bächler<thomas@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
On Fri, Nov 18, 2011 at 11:42:43AM +1100, Tom Gundersen wrote: 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