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<thomas@archlinux.org> 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