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<[email protected]> > >>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. 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
pgpjHk7u0QWhw.pgp
Description: PGP signature
