[buildd-tools-devel] Bug#762597: Bug#762597: /var/lib/schroot/mounts should be in /var/run for --one-file-system

[Roger Leigh]

On Tue, Nov 25, 2014 at 02:32:22PM +0000, Wookey wrote:
> +++ Roger Leigh [2014-11-24 13:43 +0000]:
> > On Tue, Sep 23, 2014 at 03:55:40PM +0100, Ian Jackson wrote:
> > > If you have a directory schroot chroot whose source directory is the
> > > same as /, schroot's bind mount in /var/lib/schroot/mounts is
> > > invisible to file tree walking tools.
> > > 
> > > That is, rsync --one-file-system (rsync -x), cp --one-file-system
> > > (cp -x), find -xdev, etc., do not notice the mount point, and
> > > typically traverse through it.
> > > 
> > > This is far from ideal.  Now arguably this is a bug in bind mounts
> > > (perhaps a design bug).  But as it happens it is easy to work around
> > > this problem in schroot in a way that is both correct and will fix
> > > almost all the problems:
> > > 
> > > Move /var/lib/schroot/mounts to /var/run/schroot/mounts or some such.
> > > 
> > > Typically /var/run is a tmpfs.  As a result there will be a filesystem
> > > with a different devid between / and the chroot.  So to all the file
> > > tree walkers, it will look like two mount points.  Backup tools,
> > > find, etc., will not descend into schroot's bind mount because they'll
> > > stop at /var/run.
> > 
> > Hmm, this is an interesting problem.  Your proposed solution would
> > certainly provide a boundary to stop traversal, but I'm not sure it
> > would help in all situations, since e.g. for file-based chroots we
> > unpack them under /var/lib/schroot.  Putting the mounts themselves
> > under /var/run should be safe enough though.
> 
> > I'll need to do some testing of this to make sure it doesn't
> > break anything.  If you have any further thoughts or ideas, please
> > do let me know!
> 
> As a heavy schroot user, I've certainly had plenty of (mostly minor)
> trouble with tools descending into the chroots and thus getting
> double-counting of disk usage, recursive copying, repeatedly-mounted
> locate results and so on. So I agree with Ian that it is a problem,
> and I'd like to see this improved.
> 
> I worry that using /var/run would introduce limits around the size of
> the tmpfs and recoving sessions after reboot (due to lack of
> persistence), but maybe if it really is only the mount point in there
> and not the actual data then this will work out OK? I admit to being
> vague about the details of how this all actually fits together.

/var/lib/schroot/mounts is only mounted filesystems, be it real mounts
or bind mounts from elsewhere.  So this should be safe to do, and since
it's state that's tied to this boot of the operating system, putting
it here does make some sort of sense.

/var/lib/schroot/unpack and possibly other overlay directories for
unionfs etc. under /var/lib/schroot are expected to persist their
data over reboots (for the lifetime of the session), and so these will
need to stay put and will necessarily be counted, but without the
bind mounts on /var/lib/schroot/mount, we should at least avoid the
current double-counting issue.

> So yes, please do try it and see how it works. I work mostly with
> tarball chroots and sometimes lvm chroots, and sometimes plain chroots
> so can help testing those.

Thanks.  I'll give it a whirl and if it works I'll add a git commit
for testing.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux    http://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-    GPG Public Key      F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800