[Buildd-tools-devel] Bug#354257: schroot: plain chroots should use bind mounts

Roger Leigh rleigh at whinlatter.ukfsn.org
Fri Feb 24 19:50:36 UTC 2006


Package: schroot
Version: 0.2.3-2
Severity: wishlist

It would be a nice idea if plain schroots were bind mounted into
/var/lib/schroot/mount, so that the setup scripts can be run once per
user, and at the correct times.

19:37 <dato> rleigh: I was reading yesterday some schroot/sbuild docs,
   to learnt to use the lvm-snapshot-and-throw-it-away-aftewards
   approach. so, I need a LV per chroot, in which / should directly
   contain bin/ lib/ usr/ etc., yes? and also, I guess I can make those
   LVM very very small (essential+build-ess), and make the snapshot
   bigger (eg. 3gb), does that work?

19:40 <rleigh> dato: The "source" LV needs creating with [c]debootstrap.
   This needs to be the maximum size you need (unless you mount /build
   separately).  The snapshot is copy-on-write, so needs to be big
   enough to hold all changes.  I use a 2 GiB snapshot, but OOo might
   need more.

19:42 <rleigh> dato: The schroot stuff is still fairly new at the
   moment, so I would treat it as experimental for the time being (not
   because it doesn't work, but because the schroot setup.d scripts may
   be subject to change, to make chroot setup more flexible, for
   example).

19:43 <rleigh> (currently, it's there's not much fine control over which
   setup scripts are run in each chroot, it's just a boolean option to
   run them or not)

19:43 <dato> rleigh: ok, dunno why I thought that small-source-lv,
   grow-snapshot, would work at all.

19:43 <dato> but then, I see a lot of wasted space there.

19:44 <rleigh> I'm currently using a 4 GiB source LV, and 2 GiB
   snapshot.

19:44 <rleigh> 4 GiB is probably wasteful, however.

19:45 <dato> say you have 5GB in /chroot. and you have 3 normal chroots
   there, sid, etch, sarge.

19:45 <dato> and at any time you only use one, so you can build any
   package in any of them: it'll fit.

19:45 <dato> moving to LVM, you can't have it fit, then, it seems. my
   misunderstanding, though.

19:46 <Myon> I'd prefer a userspace cow fs like fuse

19:47 <pabs> cowdancer works nicely (with pbuilder at least)

19:47 <godog> I tried a small LV -> grow it -> snapshot -> fs resize ->
   delete the snapshot -> shrink lv

19:47 <godog> seems working

19:47 <rleigh> That's correct, because you need a separate LV for each
   suite.  However, you can also use file-based chroots (sid.tar.gz,
   etch.tar.gz etc.) and it will unpack them on demand.  Other
   mechanisms are also possible; they just need
   implementing--suggestions welcome!

19:47 <dato> godog: ooh.

19:48 <dato> rleigh: cfr. godog. :)

19:48 <godog> dato: yes, I was surprised but that's correct, LVM knows
   nothing of fs

19:48 <jvw> I wonder whether that'd actually be anything faster than
   just untarring a chroot pbuilder-style...

19:48 <dato> godog: do you use schroot, or do it with some scripts of
   your own?

19:49 <godog> dato: pbuilder with custom scripts, I really need to
   polish them and make them public, stay tuned :)

19:49 <jvw> because resizing touches a lot of inodes ttbomk

19:50 <rleigh> godog: That's a cool idea.  My only concern with that is
   having to modify the source LV (schroot can handle multiple
   concurrent sessions, and this would be a bottleneck, because we use
   lockdev to lock the source LV during snapshotting).

19:50 <godog> jvw: fs resizing you mean? or lvm growiing?

19:50 <jvw> godog: fs resizing (growing)

19:50 <dato> jvw: in all filesystems? I remember at least reiser being
   fast.

19:50 <jvw> lvm growing itself isn't

19:50 <jvw> dunno, can only speak for ext2/ext3

19:51 <dato> only done it a couple times in my home server, tho, but I
   can't remember being annoyed by it being slow, at all.

19:51 <godog> rleigh: right, but you snapshot the LV just after growing,
   then shrink it to the same size, the underlying fs is untouched

19:52 <dato> godog: thanks for the idea, I think I'll be trying it.

19:52 <godog> dato: np, you're welcome :)

19:52 <rleigh> jvw: We implement the pbuilder style, too, and adding new
   chroot sources is pretty trivial if there are other more efficient
   methods.

19:53 <godog> dato: people.debian.org/~filippo/ss-{mount,umount}

19:54 <godog> dato: just a starting point though, they are highly
   untested nor polished :)

19:54 <dato> godog: cool, thanks

19:54 <rleigh> godog: I appreciate that; my concern is what happens if
   the process is interrupted somehow--this might require manual
   intervention to get a working setup.  It's a really nice idea,
   though, and I'll certainly give it a go.

19:55 <jvw> I've had serious lvm inconsistencies recently with a pvmove
   being interrupted with 2.6.8...

19:55 <godog> rleigh: ah right, you are left with a grown original LV

19:55 <jvw> couldn't recover until I tried a more recent kernel (2.6.13
   or so), at which point it just magically worked

19:56 <dato> rleigh: can sbuild use lvm-snapshots without schroot, then?

19:56 <godog> gotta go, see ya

19:57 <rleigh> dato: No.  sbuild doesn't know anything about LVM; it
   just uses schroot as a means of accessing a chroot.  All of the
   chroot types supported by schroot are transparently available to it,
   however; you just need to create a chroot by the same name as the
   distribution you are using.  It could equally be a plain directory
   like it normally uses.
   stuff is still fairly new at the moment" led me to believe that there
   was another !experimental tool for using lvm-snapshots. :)

20:00 <rleigh> No, I'm afraid not :)

20:00 <rleigh> BTW, http://paste.debian.net/4692

20:02 <rleigh> You can see here my unstable chroot is session-managed on
   LVM, but my sarge chroot is a plain directory (and is not session
   managed), but sbuild doesn't need to care about that.

20:02 <dato> sometimes one knows he'll end up building the package
   several times. I'd like to create a lvm-snapshot, install
   build-depends, and use sbuild over that, repeteadly. then throw it
   away.

20:04 <rleigh> dato: You could always use "-p never" to skip cleanup on
   the first run, and then debfoster at the end to clean up.  You'll
   need to do the initial snapshot by hand, though.

20:04 <dato> rleigh: you can't specify to sbuild the name of the schroot
   chroot, and the name of the distribution separately, can you?

20:04 <dato> rleigh: eg. you have an 'unstable' alias, but perhaps
   somebody wants to keep that for his own chroot where he does !sbuild
   stuff.

20:06 <rleigh> dato: Not at the moment.  We could, for example, check
   for an "sbuild-unstable" chroot, and fall back to "unstable" if it's
   not available.  Would that be a bit more flexible?

20:06 <dato> rleigh: sounds like a compromise.

20:07 <dato> rleigh: (thanks for the attention, btw)

20:07 <dato> oooooh.

20:07 <dato> cdebootstrap has a minimal flavour.

20:07 <rleigh> No problem.  There's always the buildd-tools-devel list
   if you want to use that.

20:08 <dato> (whishlist for debootstrap, #351912)

20:08 <dato> azeem: you may be interested in the above

20:22 <rleigh> dato: Another alternative to prefixing the name with
   "sbuild-" would be to have a second set of aliases in schroot
   ("sbuild-aliases").  There is already sbuild metadata in the config
   (priority), so we could certainly look at that.  It's not a feature
   that has been requested before, so I hadn't considered it.  However,
   the current implementation is simple, and I'd rather avoid making
   things too complicated unless we need to.

   				 * * *

20:42 <dato> rleigh: I didn't really like having bind mounted all the
   stuff for my chroots, and in this regard, I've liked
   /etc/schroot/setup.d/10mount very much, and adjusted it to run for
   'plain' chroots too.

20:43 <dato> rleigh: however, this fails if I want to schroot into the
   same chroot twice, do you have any advice? 

20:44 <dato> rleigh: does this session-managed stuff help? I thought
   about a blockdev chroot, with the "block dev" being the location of
   the current plain chroot, but that would need -o bind.

20:44 <dato> mmm, now that I think of it, perhaps I could do if -d
   $MOUNT_DEVICE; OPT=-o bind; fi; mmmm.

20:44 <dato> s/no/now/

20:49 <eigood> dato: that would still fail if you do it twice.

20:50 <eigood> dato: the entry would be fine, but what about when you
   exit?  which would would do the unmount?

20:50 <dato> eigood: if I'm not mistaken, CHROOT_MOUNT_LOCATION should
   be different in each invocation.

20:50 <eigood> hmm.

20:50 <eigood> then probably fine.

20:51 <dato> eigood: and if it isn't, then yes, I'm screwed.

20:59 <dato> oh, or I can use mount-options=-o bind

21:08 <dato> rleigh: ah no, seems like schroot won't allow a !device for
   blockdev chroots. any suggestions welcome.

22:06 <rleigh> dato: Sorry for the delay (just got back from watching
   Aeon Flux).  I'd like to make the setup.d/10mount (and other setup
   scripts) read a per-chroot configuration script to make this rather
   more configurable (other suggestions for this are welcome).  I'm not
   quite sure about what you mean with the blockdev chroots; could you
   give a bit more detail about what you'd like to do?

22:08 <rleigh> "block-device" chroots shouldn't be accessible twice
   simultaneously due to lockdev locking, which prevents the setup stuff
   being run twice.

22:12 <dato> rleigh: aha wrt block-device chroots.

22:13 <dato> rleigh: what I'm looking into: have my plain chroots
   managed by schroot, and that schroot mounts the necessary filesystems
   upon entering (ie., no need for me to keep them in /etc/fstab, and no
   need for them to be mounted if the chroot is not in use), but in a

22:23 <rleigh> dato: Ah, I see.  The problem with the
   non-session-managed "plain" andf "block-device" chroot type is that
   there is not currently any means of counting the number of active
   users, and therefore we never know when to run the setup scripts for
   shutdown.  If that's something that would be useful, we can certainly
   implement that (it would require writing out the session metadata
   like for sessions, adding an active user count there).

22:24 <rleigh> We already implement the necessary file locking, so this
   shouldn't be a major problem.

22:29 <rleigh> If you would find this useful, I'll make sure to add it
   to the TODO list for the next release.

23:44 <dato> rleigh: well, I'd _certainly_ welcome it, thanks. that bit
   about writing metadata sounds complex, but I guess it's how shcroot
   is best prepared to handle the situation if you share the mount point
   across session. one option I mentioned above for plain chroots was to
   bindmount in eg. /var/lib/schroot/mount/name-`rnd`, so you don't have
   to worry about sessions. that may be a bit un-schroot-esque, tho. :)

23:48 <rleigh> dato: I think the bindmount suggestion is equally good
   (and, in fact, much more robust and simpler to implement); I just
   didn't fully understand your point above, it now makes good sense.


Regards,
Roger

-- 
Roger Leigh
                Printing on GNU/Linux?  http://gutenprint.sourceforge.net/
                Debian GNU/Linux        http://www.debian.org/
                GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20060224/85bf3add/attachment.pgp


More information about the Buildd-tools-devel mailing list