Bug#947919: schroot: Support for ZFS snapshotting

[Steve Langasek]

On Sun, Jan 05, 2020 at 08:23:33PM +, Roger Leigh wrote:
> On 05/01/2020 19:54, Steve Langasek wrote:
> 
> > On Sun, Jan 05, 2020 at 09:16:34AM +, Roger Leigh wrote:
> > > sbuild::chroot::ptr
> > > chroot_zfs_snapshot::clone_source () const
> > > {
> > >    ptr clone(new chroot_zfs_snapshot(*this));
> > > 
> > > ...
> > > 
> > > should be
> > > 
> > > chroot_zfs_snapshot::clone_source () const
> > > {
> > >    ptr clone(new chroot_directory(*this));
> > > 
> > >    chroot_facet_source_clonable::const_ptr psrc
> > >      (get_facet());
> > >    assert(psrc);
> > > 
> > >    psrc->clone_source_setup(*this, clone);
> > > 
> > >    return clone;
> > > }
> > I did look into this as an option, but got tangled up because the source of
> > a zfs clone is not a directory, it's a dataset - which means it is not an
> > absolute filesystem path and is not stat()able.  Rather than hacking the
> > directory implementation to relax these constraints and make it compatible
> > with zfs, I decided to keep the zfs implementation self-contained.

> Sure, that's completely understandable, but you could set the path to be the
> mountpoint of the dataset and have it work correctly this way.

And the user would have to declare both the mountpoint and the dataset name
in the schroot.conf?  That would be bad UX.

Or else the schroot C++ code would have to call into zfs client code to
retrieve the mountpoint of the dataset, just to meet the constraints of the
chroot type.

And there's actually no reason that the dataset needs to HAVE a defined
mountpoint.  With the current implementation, you'd set mountpoint=legacy on
the dataset, and it is mounted by schroot only when needed.

> The problem that I see with the current approach is that the source chroot
> session is using a cloned copy of the dataset, just like a regular session,
> and when you end that session, you'll lose the changes.

Sorry, that's not the case.  Are you looking at the first version of my
patch, or the second?  The first version was buggy in precisely this way. 
The second version works correctly, mounting the source dataset, not a
clone.

> If the 05zfs script special-cased source chroots,

It does in the sense that when called for a source chroot, the zfs-snapshot
code does not set up the clone/snapshot variables, making 05zfs a no-op.


-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#947919: schroot: Support for ZFS snapshotting

[Roger Leigh]

On 05/01/2020 19:54, Steve Langasek wrote:


On Sun, Jan 05, 2020 at 09:16:34AM +, Roger Leigh wrote:

sbuild::chroot::ptr
chroot_zfs_snapshot::clone_source () const
{
   ptr clone(new chroot_zfs_snapshot(*this));

...

should be

chroot_zfs_snapshot::clone_source () const
{
   ptr clone(new chroot_directory(*this));

   chroot_facet_source_clonable::const_ptr psrc
     (get_facet());
   assert(psrc);

   psrc->clone_source_setup(*this, clone);

   return clone;
}

I did look into this as an option, but got tangled up because the source of
a zfs clone is not a directory, it's a dataset - which means it is not an
absolute filesystem path and is not stat()able.  Rather than hacking the
directory implementation to relax these constraints and make it compatible
with zfs, I decided to keep the zfs implementation self-contained.


Sure, that's completely understandable, but you could set the path to be 
the mountpoint of the dataset and have it work correctly this way.


The problem that I see with the current approach is that the source 
chroot session is using a cloned copy of the dataset, just like a 
regular session, and when you end that session, you'll lose the 
changes.  They won't be preserved in the original dataset.  I might be 
misreading things, but that's what it looks like would happen.  That 
looks fundamentally incompatible with how source chroot sessions are 
supposed to work.  It must work on the source dataset or else it's not 
going to change it as intended.


If the 05zfs script special-cased source chroots, then you could keep 
the existing approach on the C++ side, but skip the snapshot/clone in 
the script and work directly with the original dataset.  But I don't 
currently see any logic to handle this; it's snapshotting and cloning 
unconditionally.


I see two possible approaches:

1) Keep the current code, but unset the clone/snapshot settings and use 
05zfs to special-case the snapshot/clone creation and deletion for 
chroot sessions only, and skip entirely for source sessions.  You could 
do this if the source dataset and clone dataset names are the same.  Set 
the variables so that it will use the mountpoint for the source dataset.


2) Use a directory chroot.  Obtain the mountpoint path of the source 
dataset from zfs so it can be stat()ed


(1) looks simplest to do; it's just a single conditional in 05zfs to 
skip the snapshot/clone stuff.



Regards,

Roger

Bug#947919: schroot: Support for ZFS snapshotting

[Steve Langasek]

On Sun, Jan 05, 2020 at 09:16:34AM +, Roger Leigh wrote:
> > Ok, you're right that I haven't done anything wrt 'zfs promote'.  Prior to
> > switching to zfs, all of my schroot work used the lvm-snapshot type, which
> > has the same limitation you describe here: session clones taken while the
> > source chroot is in the process of being updated end up cloning some
> > intermediate state.  I have never had a problem with this limitation in
> > practice, since my usage of schroot is entirely human-driven, so it's very
> > easy for me to avoid launching new schroots while in the middle of a
> > "maintenance window".

> > Being able to update the source atomically certainly seems like a nice
> > enhancement, but given that the implementation is currently at parity with
> > the lvm-snapshot type, I am not likely to invest effort in this myself at
> > this time.

> In this case, I think you should copy the btrfs-snapshot approach and make
> the source chroot a "directory" chroot type.  Then it will operate directly
> on the source dataset.  That is to say:

> sbuild::chroot::ptr
> chroot_zfs_snapshot::clone_source () const
> {
>   ptr clone(new chroot_zfs_snapshot(*this));
> 
> ...
> 
> should be
> 
> chroot_zfs_snapshot::clone_source () const
> {
>   ptr clone(new chroot_directory(*this));
> 
>   chroot_facet_source_clonable::const_ptr psrc
>     (get_facet());
>   assert(psrc);
> 
>   psrc->clone_source_setup(*this, clone);
> 
>   return clone;
> }

I did look into this as an option, but got tangled up because the source of
a zfs clone is not a directory, it's a dataset - which means it is not an
absolute filesystem path and is not stat()able.  Rather than hacking the
directory implementation to relax these constraints and make it compatible
with zfs, I decided to keep the zfs implementation self-contained.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#947919: schroot: Support for ZFS snapshotting

[Roger Leigh]

On 05/01/2020 02:23, Steve Langasek wrote:


Hi Roger,

On Sat, Jan 04, 2020 at 12:54:56PM +, Roger Leigh wrote:

When you clone a source snapshot, we want to make that snapshot the 
default

state for the original dataset when you end the session.  The "file" chroot
type is the most comparable here; the LVM and Btrfs snapshots operate
directly on the original copy. Right now the ZFS source chroot clone looks
as ephemeral as a regular cloned session, so I'm not sure the current
behaviour is corect.  We want the saving of the updated source chroot to be
done such that it appears atomic for any concurrent usage to clone the old
state or the new state, and never an intermediate state as the original is
updated.  It's this part that I wasn't sure about.  I don't see an
equivalent to "zfs promote" which would allow copying back a clone (or
snapshot of a clone) to the source dataset, and I don't see any
source-chroot-specific logic in 05zfs which would preserve any source chroot
changes.

Ok, you're right that I haven't done anything wrt 'zfs promote'.  Prior to
switching to zfs, all of my schroot work used the lvm-snapshot type, which
has the same limitation you describe here: session clones taken while the
source chroot is in the process of being updated end up cloning some
intermediate state.  I have never had a problem with this limitation in
practice, since my usage of schroot is entirely human-driven, so it's very
easy for me to avoid launching new schroots while in the middle of a
"maintenance window".

Being able to update the source atomically certainly seems like a nice
enhancement, but given that the implementation is currently at parity with
the lvm-snapshot type, I am not likely to invest effort in this myself at
this time.


In this case, I think you should copy the btrfs-snapshot approach and 
make the source chroot a "directory" chroot type.  Then it will operate 
directly on the source dataset.  That is to say:


sbuild::chroot::ptr
chroot_zfs_snapshot::clone_source () const
{
  ptr clone(new chroot_zfs_snapshot(*this));

...

should be

chroot_zfs_snapshot::clone_source () const
{
  ptr clone(new chroot_directory(*this));

  chroot_facet_source_clonable::const_ptr psrc
    (get_facet());
  assert(psrc);

  psrc->clone_source_setup(*this, clone);

  return clone;
}

This isn't quite as elegant as doing an atomic update, but if it's 
primarily under the user's control rather than being scripted and done 
automatically then it should be good enough, and it matches the 
constraints the other chroot snapshot types have operated under.


I would certainly be happy to see a more sophisticated approach in the 
future which provides some form of atomic update and guarantees cloning 
new sessions will always use a known good state, but this will clearly 
need more work to do properly.



Kind regards,

Roger

Bug#947919: schroot: Support for ZFS snapshotting

[Steve Langasek]

Hi Roger,

On Sat, Jan 04, 2020 at 12:54:56PM +, Roger Leigh wrote:

> If you hadn't already seen it, there's an existing implementation here:

> https://gitlab.com/rleigh/schroot/commit/08751fdff2db4d11731983faf8e9868dffbd5dbf

Ah no, I had not seen this!  There don't appear to be any references to this
gitlab repository anywhere in the existing source package.

> I don't know if your work was using this as a basis for your work on top of
> the 1.6 branch (the work here is against master, which is a bit different). 
> If you haven't already, it might be worth looking though.  I think, overall,
> your implementation is better in terms of the options it provides and the
> environment it sets, but it might be useful to compare just in case it has
> any interesting bits you want to pick up.  Note that I didn't complete this
> work; the C++ side was mostly done but the scripting side for setting up the
> ZFS snapshots was not.  At the time, I wasn't entirely sure on how best to
> use ZFS to implement source chroots reliably, which I think you've done
> better but I think not completely (as detailed below).

I'm largely happy with what I have here now, but if you think there are
specific learnings I should take from your branch, I'm happy to look.

> When you clone a snapshot, you're getting an ephemeral dataset and snapshot
> which the 05zfs script is correctly creating and destroying.  No problems
> here that I can see.

> When you clone a source snapshot, we want to make that snapshot the default
> state for the original dataset when you end the session.  The "file" chroot
> type is the most comparable here; the LVM and Btrfs snapshots operate
> directly on the original copy. Right now the ZFS source chroot clone looks
> as ephemeral as a regular cloned session, so I'm not sure the current
> behaviour is corect.  We want the saving of the updated source chroot to be
> done such that it appears atomic for any concurrent usage to clone the old
> state or the new state, and never an intermediate state as the original is
> updated.  It's this part that I wasn't sure about.  I don't see an
> equivalent to "zfs promote" which would allow copying back a clone (or
> snapshot of a clone) to the source dataset, and I don't see any
> source-chroot-specific logic in 05zfs which would preserve any source chroot
> changes.

Ok, you're right that I haven't done anything wrt 'zfs promote'.  Prior to
switching to zfs, all of my schroot work used the lvm-snapshot type, which
has the same limitation you describe here: session clones taken while the
source chroot is in the process of being updated end up cloning some
intermediate state.  I have never had a problem with this limitation in
practice, since my usage of schroot is entirely human-driven, so it's very
easy for me to avoid launching new schroots while in the middle of a
"maintenance window".

Being able to update the source atomically certainly seems like a nice
enhancement, but given that the implementation is currently at parity with
the lvm-snapshot type, I am not likely to invest effort in this myself at
this time.

> I'm sure some strategy could be worked out; these considerations were the
> primary reason I never merged in that branch and made a new major release of
> schroot.  If you or anyone else has better expertise on how to safely
> implement this, I'd be happy to work on merging your work into the master
> branch and releasing this.  Note however, that the master schroot branch did
> made some incompatible configuration changes.  The biggest change was
> dropping support for the lvm-snapshot and btrfs-snapshot chroot types, which
> in practice have proven quite unreliable due to kernel and other
> implementation bugs, including races in udev when using LVM and filesytem
> unbalancing and dataloss with Btrfs.  zfs-snapshot should be free of all
> these irritations.

> Lastly, I saw the buildds were failing due to an issue with the unit test;
> looks like it needs updating to match the configuration serialisation?

This it turns out was caused by a bug in debian/rules, which failed to run
the test suite at all when called via dpkg-buildpackage -b (instead of -B).
I recall being surprised that my changes didn't introduce any new test
failures, but failed to notice the tests were not being run.  I'll follow
through on this, thanks for bringing it to my attention.

On Sat, Jan 04, 2020 at 02:35:47PM +, Roger Leigh wrote:
> On 04/01/2020 12:54, Roger Leigh wrote:
> 
> > When you clone a source snapshot, we want to make that snapshot the
> > default state for the original dataset when you end the session. The
> > "file" chroot type is the most comparable here; the LVM and Btrfs
> > snapshots operate directly on the original copy. Right now the ZFS
> > source chroot clone looks as ephemeral as a regular cloned session, so
> > I'm not sure the current behaviour is corect.  We want the saving of the
> > updated source chroot to be done such that it appears 

Bug#947919: schroot: Support for ZFS snapshotting

[Roger Leigh]

On 04/01/2020 12:54, Roger Leigh wrote:

When you clone a source snapshot, we want to make that snapshot the 
default state for the original dataset when you end the session. The 
"file" chroot type is the most comparable here; the LVM and Btrfs 
snapshots operate directly on the original copy. Right now the ZFS 
source chroot clone looks as ephemeral as a regular cloned session, so 
I'm not sure the current behaviour is corect.  We want the saving of 
the updated source chroot to be done such that it appears atomic for 
any concurrent usage to clone the old state or the new state, and 
never an intermediate state as the original is updated.  It's this 
part that I wasn't sure about.  I don't see an equivalent to "zfs 
promote" which would allow copying back a clone (or snapshot of a 
clone) to the source dataset, and I don't see any 
source-chroot-specific logic in 05zfs which would preserve any source 
chroot changes.


I should also have written that I did also consider if we could use "zfs 
promote" as intended.  It should be fine for its intended purpose, but 
it would change the dataset name which would then require an update of 
schroot.conf.  I ruled this out because it doesn't fit into the existing 
design.  However, were schroot to eventually become a service, we could 
create and manage chroots similar to docker and not have the chroot 
configuration in /etc at all; it would be all stored as data under /var.

Bug#947919: schroot: Support for ZFS snapshotting

[Roger Leigh]

On 03/01/2020 20:44, Steve Langasek wrote:


Package: schroot
Followup-For: Bug #947919
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Attached is an updated patch which implements source chroots as well.


Dear Steve,


I've had a look over the patch, and have a few comments on it.


Firstly, it looks really great.  I've no major criticisms to make of it, 
so many thanks for taking the time and effort to implement this, it's a 
great addition.



If you hadn't already seen it, there's an existing implementation here:

https://gitlab.com/rleigh/schroot/commit/08751fdff2db4d11731983faf8e9868dffbd5dbf

on this branch:

  https://gitlab.com/rleigh/schroot/tree/zfs-snapshot

I don't know if your work was using this as a basis for your work on top 
of the 1.6 branch (the work here is against master, which is a bit 
different).  If you haven't already, it might be worth looking though.  
I think, overall, your implementation is better in terms of the options 
it provides and the environment it sets, but it might be useful to 
compare just in case it has any interesting bits you want to pick up.  
Note that I didn't complete this work; the C++ side was mostly done but 
the scripting side for setting up the ZFS snapshots was not.  At the 
time, I wasn't entirely sure on how best to use ZFS to implement source 
chroots reliably, which I think you've done better but I think not 
completely (as detailed below).



When you clone a snapshot, you're getting an ephemeral dataset and 
snapshot which the 05zfs script is correctly creating and destroying.  
No problems here that I can see.



When you clone a source snapshot, we want to make that snapshot the 
default state for the original dataset when you end the session.  The 
"file" chroot type is the most comparable here; the LVM and Btrfs 
snapshots operate directly on the original copy. Right now the ZFS 
source chroot clone looks as ephemeral as a regular cloned session, so 
I'm not sure the current behaviour is corect.  We want the saving of the 
updated source chroot to be done such that it appears atomic for any 
concurrent usage to clone the old state or the new state, and never an 
intermediate state as the original is updated.  It's this part that I 
wasn't sure about.  I don't see an equivalent to "zfs promote" which 
would allow copying back a clone (or snapshot of a clone) to the source 
dataset, and I don't see any source-chroot-specific logic in 05zfs which 
would preserve any source chroot changes.


One possible method would be to create an @latest snapshot which would 
be used in preference to creating a new snapshot should it exist, so 
that we could copy the content over while this snapshot exists.  The 
implementation would have to cope with races if it's deleted before 
cloning, however, by falling back to creating a new snapshot.  And only 
the original creator should be deleting it, so it would also have to 
cope with deleting it if the original process aborted without deleting it.


Another alternative which springs to mind is to make the source chroot a 
directory chroot type, so it's working directly on the source dataset.  
But snapshot with @latest-source and when others start a session, clone 
that tag.  When you end the session, update that tag.  There's also the 
option of rollback if you want to throw away the changes.  This would 
restrict you to one source chroot session at a time, but it's simpler 
and has less to deal with in terms of races, and fits in a bit better 
with how ZFS wants things done.


I'm sure some strategy could be worked out; these considerations were 
the primary reason I never merged in that branch and made a new major 
release of schroot.  If you or anyone else has better expertise on how 
to safely implement this, I'd be happy to work on merging your work into 
the master branch and releasing this.  Note however, that the master 
schroot branch did made some incompatible configuration changes.  The 
biggest change was dropping support for the lvm-snapshot and 
btrfs-snapshot chroot types, which in practice have proven quite 
unreliable due to kernel and other implementation bugs, including races 
in udev when using LVM and filesytem unbalancing and dataloss with 
Btrfs.  zfs-snapshot should be free of all these irritations.



Another comment regarding updating of the source chroot.  With the 
current methods, primarily 05file, the source is unconditionally updated 
(repacked) when the session is ended. I've always been a little unhapy 
with this, in case you mess things up and want to throw it away.  This 
would require an additional option adding to schroot to pass through 
with --end-session.  It would be a session option like --session-name. 
Maybe --save-session to require the overwriting.  Or a negative option 
if you want the default to be to save.  Or a Boolean option to make it 
explicit and mandatory.  With the @latest-source, above, this could 
invoke "zfs 

Bug#947919: schroot: Support for ZFS snapshotting

[Steve Langasek]

Package: schroot
Followup-For: Bug #947919
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Attached is an updated patch which implements source chroots as well.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru schroot-1.6.10/debian/control schroot-1.6.10/debian/control
--- schroot-1.6.10/debian/control   2018-09-01 00:25:59.0 -0700
+++ schroot-1.6.10/debian/control   2019-12-30 21:59:11.0 -0800
@@ -54,7 +54,7 @@
  sbuild (<< 0.62.6),
 # We need the --find option of update-binfmts
  binfmt-support (<< 2.0.1)
-Suggests: debootstrap, lvm2, btrfs-tools, aufs-tools | unionfs-fuse, 
qemu-user-static
+Suggests: debootstrap, lvm2, btrfs-tools, zfsutils-linux, aufs-tools | 
unionfs-fuse, qemu-user-static
 Description: Execute commands in a chroot environment
  schroot allows users to execute commands or interactive shells in
  different chroots.  Any number of named chroots may be created, and
@@ -67,7 +67,7 @@
  Several different types of chroot are supported, including normal
  directories in the filesystem, and also block devices.  Sessions,
  persistent chroots created on the fly from files (tar with optional
- compression) and Btrfs and LVM snapshots are also supported.
+ compression) and Btrfs, ZFS, and LVM snapshots are also supported.
  .
  schroot supports kernel personalities, allowing the programs run
  inside the chroot to have a different personality.  For example,
@@ -76,7 +76,7 @@
  .
  schroot also integrates with sbuild, to allow building packages with
  all supported chroot types, including session-managed chroot types
- such as Btrfs and LVM snapshots.
+ such as Btrfs, ZFS, and LVM snapshots.
  .
  schroot shares most of its options with dchroot, but offers vastly
  more functionality.
diff -Nru schroot-1.6.10/debian/patches/series 
schroot-1.6.10/debian/patches/series
--- schroot-1.6.10/debian/patches/series2018-09-01 00:25:59.0 
-0700
+++ schroot-1.6.10/debian/patches/series2019-12-30 21:59:11.0 
-0800
@@ -13,3 +13,4 @@
 update_czech_schroot_translation.patch
 update_french_schroot_manpage_translation_2018.patch
 update_german_schroot_manpage_translation_2018.patch
+zfs-snapshot-support.patch
diff -Nru schroot-1.6.10/debian/patches/zfs-snapshot-support.patch 
schroot-1.6.10/debian/patches/zfs-snapshot-support.patch
--- schroot-1.6.10/debian/patches/zfs-snapshot-support.patch1969-12-31 
16:00:00.0 -0800
+++ schroot-1.6.10/debian/patches/zfs-snapshot-support.patch2019-12-30 
21:59:11.0 -0800
@@ -0,0 +1,1189 @@
+Description: add support for a zfs-snapshot backend.
+Author: Steve Langasek 
+Last-Update: 2020-01-03
+
+Index: schroot-1.6.10/sbuild/sbuild-chroot-zfs-snapshot.cc
+===
+--- /dev/null
 schroot-1.6.10/sbuild/sbuild-chroot-zfs-snapshot.cc
+@@ -0,0 +1,304 @@
++/* Copyright © 2005-2009  Roger Leigh 
++ * Copyright © 2019   Steve Langasek 
++ *
++ * schroot is free software: you can redistribute it and/or modify it
++ * under the terms of the GNU General Public License as published by
++ * the Free Software Foundation, either version 3 of the License, or
++ * (at your option) any later version.
++ *
++ * schroot is distributed in the hope that it will be useful, but
++ * WITHOUT ANY WARRANTY; without even the implied warranty of
++ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
++ * General Public License for more details.
++ *
++ * You should have received a copy of the GNU General Public License
++ * along with this program.  If not, see
++ * .
++ *
++ */
++
++#include 
++
++#include "sbuild-chroot-zfs-snapshot.h"
++#include "sbuild-chroot-facet-session.h"
++#include "sbuild-chroot-facet-session-clonable.h"
++#include "sbuild-chroot-facet-source-clonable.h"
++#include "sbuild-chroot-facet-source.h"
++#include "sbuild-chroot-facet-mountable.h"
++#include "sbuild-format-detail.h"
++
++#include 
++#include 
++
++#include 
++
++using std::endl;
++using boost::format;
++using namespace sbuild;
++
++chroot_zfs_snapshot::chroot_zfs_snapshot ():
++  chroot(),
++  dataset(),
++  clone_name(),
++  snapshot_name(),
++  snapshot_options()
++{
++  add_facet(chroot_facet_source_clonable::create());
++  add_facet(chroot_facet_mountable::create());
++}
++
++chroot_zfs_snapshot::chroot_zfs_snapshot (const chroot_zfs_snapshot& rhs):
++  chroot(rhs),
++  dataset(rhs.dataset),
++  clone_name(rhs.clone_name),
++  snapshot_name(rhs.snapshot_name),
++  snapshot_options(rhs.snapshot_options)
++{
++}
++
++chroot_zfs_snapshot::~chroot_zfs_snapshot ()
++{
++}

Bug#947919: schroot: Support for ZFS snapshotting

[Georgy Yakovlev]

Hi,

by coincidence I was also working on zfs support in schroot today
and randomly found this fresh patch.

I have no C++ skills and was just doing custom type, but concept is the
same.

It's a log not from a debian system, but maybe this will be useful in
polishing this patch


Details:

all debian patches applied
ppc64le
gcc-9.2.0
boost 1.72.0

Error:

[ 61%] Built target dchroot-common
[ 63%] Building CXX object
sbuild/CMakeFiles/sbuild.dir/sbuild-chroot-facet-union.cc.o cd
/var/tmp/portage/dev-util/schroot-1.6.10-r5/work/schroot-1.6.10_build/sbuild
&& /usr/bin/powerpc64le-unknown-linux-gnu-g++
-I/var/tmp/portage/dev-util/schroot-1.6.10-r5/work/schroot-1.6.10_build/lib
-I/var/tmp/portage/dev-util/schroot-1.6.10-r5/work/schroot-1.6.10/lib
-I/var/tmp/portage/dev-util/schroot-1.6.10-r5/work/schroot-1.6.10_build
-I/var/tmp/portage/dev-util/schroot-1.6.10-r5/work/schroot-1.6.10
-I/var/tmp/portage/dev-util/schroot-1.6.10-r5/work/schroot-1.6.10/sbuild
-I/var/tmp/portage/dev-util/schroot-1.6.10-r5/work/schroot-1.6.10_build/sbuild
  -DNDEBUG -mcpu=native -O2 -pipe -frecord-gcc-switches
-fdiagnostics-show-option -std=c++11 -pedantic -Wall -Wcast-align
-Wwrite-strings -Wswitch-default -Wcast-qual -Wunused-variable
-Wredundant-decls -Wctor-dtor-privacy -Wnon-virtual-dtor -Wreorder
-Wold-style-cast -Woverloaded-virtual -fstrict-aliasing   -o
CMakeFiles/sbuild.dir/sbuild-chroot-facet-union.cc.o -c
/var/tmp/portage/dev-util/schroot-1.6.10-r5/work/schroot-1.6.10/sbuild/sbuild-chroot-facet-union.cc
/var/tmp/portage/dev-util/schroot-1.6.10-r5/work/schroot-1.6.10/sbuild/sbuild-chroot-zfs-snapshot.cc:
In member function 'virtual sbuild::chroot::ptr
sbuild::chroot_zfs_snapshot::clone_source() const':
/var/tmp/portage/dev-util/schroot-1.6.10-r5/work/schroot-1.6.10/sbuild/sbuild-chroot-zfs-snapshot.cc:93:42:
error: 'sbuild::chroot_block_device::chroot_block_device(const
sbuild::chroot_zfs_snapshot&)' is protected within this context 93 |
ptr clone(new chroot_block_device(*this)); |
  ^ In file included from
/var/tmp/portage/dev-util/schroot-1.6.10-r5/work/schroot-1.6.10/sbuild/sbuild-chroot-zfs-snapshot.cc:23:
/var/tmp/portage/dev-util/schroot-1.6.10-r5/work/schroot-1.6.10/sbuild/sbuild-chroot-block-device.h:55:5:
note: declared protected here 55 | chroot_block_device (const
chroot_zfs_snapshot& rhs); | ^~~ make[2]: ***
[sbuild/CMakeFiles/sbuild.dir/build.make:466:
sbuild/CMakeFiles/sbuild.dir/sbuild-chroot-zfs-snapshot.cc.o] Error 1
make[2]: *** Waiting for unfinished jobs


Regards, Georgy.

Bug#947919: schroot: Support for ZFS snapshotting

[Steve Langasek]

Package: schroot
Version: 1.6.10-6.1
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

schroot currently supports using LVM and btrfs volumes as a source for
snapshot-based chroots, to good effect.  It is also possible to use ZFS as a
filesystem on Linux, via the zfs-linux package; it would be useful to users
of ZFS for schroot to support ZFS snapshots in addition to the other two
snapshot-based backends.

Attached is a preliminary patch which adds support for a zfs-snapshot type. 
It currently has a bug I've only just detected which prevents it from
working correctly for source chroots, so I'll revise it shortly.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru schroot-1.6.10/debian/control schroot-1.6.10/debian/control
--- schroot-1.6.10/debian/control   2018-09-01 02:25:59.0 -0500
+++ schroot-1.6.10/debian/control   2019-12-30 23:59:11.0 -0600
@@ -54,7 +54,7 @@
  sbuild (<< 0.62.6),
 # We need the --find option of update-binfmts
  binfmt-support (<< 2.0.1)
-Suggests: debootstrap, lvm2, btrfs-tools, aufs-tools | unionfs-fuse, 
qemu-user-static
+Suggests: debootstrap, lvm2, btrfs-tools, zfsutils-linux, aufs-tools | 
unionfs-fuse, qemu-user-static
 Description: Execute commands in a chroot environment
  schroot allows users to execute commands or interactive shells in
  different chroots.  Any number of named chroots may be created, and
@@ -67,7 +67,7 @@
  Several different types of chroot are supported, including normal
  directories in the filesystem, and also block devices.  Sessions,
  persistent chroots created on the fly from files (tar with optional
- compression) and Btrfs and LVM snapshots are also supported.
+ compression) and Btrfs, ZFS, and LVM snapshots are also supported.
  .
  schroot supports kernel personalities, allowing the programs run
  inside the chroot to have a different personality.  For example,
@@ -76,7 +76,7 @@
  .
  schroot also integrates with sbuild, to allow building packages with
  all supported chroot types, including session-managed chroot types
- such as Btrfs and LVM snapshots.
+ such as Btrfs, ZFS, and LVM snapshots.
  .
  schroot shares most of its options with dchroot, but offers vastly
  more functionality.
diff -Nru schroot-1.6.10/debian/patches/series 
schroot-1.6.10/debian/patches/series
--- schroot-1.6.10/debian/patches/series2018-09-01 02:25:59.0 
-0500
+++ schroot-1.6.10/debian/patches/series2019-12-30 19:40:44.0 
-0600
@@ -13,3 +13,4 @@
 update_czech_schroot_translation.patch
 update_french_schroot_manpage_translation_2018.patch
 update_german_schroot_manpage_translation_2018.patch
+zfs-snapshot-support.patch
diff -Nru schroot-1.6.10/debian/patches/zfs-snapshot-support.patch 
schroot-1.6.10/debian/patches/zfs-snapshot-support.patch
--- schroot-1.6.10/debian/patches/zfs-snapshot-support.patch1969-12-31 
18:00:00.0 -0600
+++ schroot-1.6.10/debian/patches/zfs-snapshot-support.patch2019-12-30 
23:59:11.0 -0600
@@ -0,0 +1,1186 @@
+Description: add support for a zfs-snapshot backend.
+Author: Steve Langasek 
+Last-Update: 2020-01-01
+
+Index: schroot-1.6.10/sbuild/sbuild-chroot-zfs-snapshot.cc
+===
+--- /dev/null
 schroot-1.6.10/sbuild/sbuild-chroot-zfs-snapshot.cc
+@@ -0,0 +1,259 @@
++/* Copyright © 2005-2009  Roger Leigh 
++ * Copyright © 2019   Steve Langasek 
++ *
++ * schroot is free software: you can redistribute it and/or modify it
++ * under the terms of the GNU General Public License as published by
++ * the Free Software Foundation, either version 3 of the License, or
++ * (at your option) any later version.
++ *
++ * schroot is distributed in the hope that it will be useful, but
++ * WITHOUT ANY WARRANTY; without even the implied warranty of
++ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
++ * General Public License for more details.
++ *
++ * You should have received a copy of the GNU General Public License
++ * along with this program.  If not, see
++ * .
++ *
++ */
++
++#include 
++
++#include "sbuild-chroot-zfs-snapshot.h"
++#include "sbuild-chroot-block-device.h"
++#include "sbuild-chroot-facet-session.h"
++#include "sbuild-chroot-facet-session-clonable.h"
++#include "sbuild-chroot-facet-source-clonable.h"
++#include "sbuild-chroot-facet-mountable.h"
++#include "sbuild-format-detail.h"
++
++#include 
++#include 
++
++#include 
++
++using std::endl;
++using boost::format;
++using namespace sbuild;
++
++chroot_zfs_snapshot::chroot_zfs_snapshot ():
++