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). Other than that, people WILL complain.

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

On Thu, Nov 17, 2011 at 10:51:37PM -0300, Gerardo Exequiel Pozzi wrote:

On 11/17/2011 10:21 PM, Dave Reisner 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

On Fri, Nov 18, 2011 at 5:23 AM, Thomas Bächler wrote: 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. 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 /

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

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:

...

...

...

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

On Fri, Nov 18, 2011 at 5:23 AM, Thomas Bächler wrote: 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'.

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

On Fri, Nov 18, 2011 at 12:12:28AM -0300, Gerardo Exequiel Pozzi wrote:

On 11/18/2011 12:03 AM, Dave Reisner wrote:

...

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

Ahh, there's the lightbulb. More specifically, directories in the root can't be bind mounted. Seems the inverse doesn't hold true. [ramfs /]# mkdir /a [ramfs /]# mount -B /run/initramfs/ /a [ramfs /]# umount /a [ramfs /]# mount -B /a /run/initramfs/ mount: wrong fs type, bad option, bad superblock on /a, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so (oh the joys of the soul-less vacuum that is early userspace) d

On Fri, Nov 18, 2011 at 12:44:51AM -0300, Gerardo Exequiel Pozzi wrote:

On 11/18/2011 12:22 AM, Dave Reisner wrote:

...

On Fri, Nov 18, 2011 at 12:12:28AM -0300, Gerardo Exequiel Pozzi wrote:

...

On 11/18/2011 12:03 AM, Dave Reisner wrote:

...

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

Ahh, there's the lightbulb. More specifically, directories in the root can't be bind mounted. Seems the inverse doesn't hold true. Not exactly. you are mixing things. /run is on another filesystem

When I say rootfs I talk about of a type of filesystem.

Do not confuse, rootfs (an special tmpfs/ramfs is the head, it does not have a name, you can not reference, this implies you can not unmount, bind, move and pivot).

d'oh, right. poor place to test my assumptions. time for sleep, dave. yeah, it all makes sense.

...

[ramfs /]# mkdir /a [ramfs /]# mount -B /run/initramfs/ /a

works because you are binding a tmpfs. repeat the same with /somedir/lalala, the result is exactly as below....

...

[ramfs /]# umount /a

...

[ramfs /]# mount -B /a /run/initramfs/ mount: wrong fs type, bad option, bad superblock on /a, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so does not works because you are trying to reference an "unnamed" mountpoint. There is no "source" for such fs.

...

(oh the joys of the soul-less vacuum that is early userspace)

d

haha :P

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

On 11/18/2011 03:26 AM, Tom Gundersen wrote:

On Fri, Nov 18, 2011 at 1: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:

...

...

...

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

On Fri, Nov 18, 2011 at 5:23 AM, Thomas Bächler wrote: 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. 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 /

...

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. Thanks for the explanations Dave and Gerardo.

I agree that it would be best to just copy everything, which would not require us to do anything fancy.

Still not sold on making it optional though. At least wait until someone can point to a use-case and some numbers that shows a real problem. If the initramfs is sufficiently huge, the time taken to copy it to /run would obviously be measurable. However, the time taken to extract the initramfs in the first place would probably dwarf this number.

If we start making things optional we'd have something like this:

copying /run/initramfs is required by "shutdown" and "shutdown" is required by "usr".

But all users who have a separate /usr must use the "usr" hook, and all users really should use the "shutdown" hook. So unless we find a case where including a hook causes some sort of real downside I'd say just make it unconditional, and thereby reduce the number of configurations we'd have to test.

...

From the point of view of initscripts it would be very nice to know that /usr is always mounted, and if the rootfs is on lvm or something like that it will always be torn down properly, without worrying about users possibly disabling these hooks in mkinitcpio.

Just my two cents.

-t

You are welcome! Note that you can bind mount some dir (outside rootfs) for example in /run, the overlap /lib/modules. Anyway the copy can be done at end of init just before switch_root, just after udev stopped. so you can rm -r /lib/modules ; cp -ax / /run/initramfs PS: uncompressed archiso.img is 22M. -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1