[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