ZFS is now offered in Kubuntu 19.10 as a root file system.
Jack Wallen
https://thenewstack.io/how-to-create...-ubuntu-19-10/
You install it as the root file system exactly the same way you would install BTRFS as the root file system.
With BTRFS two subvolumes are created: @root and @home. ZFS creates what are called "datasets", which are created inside of "pools". During installation two pools are created: bpool and rpool (boot and root). Wallen gives a listing of pools, their datasets and resulting mount points.
Notice that /home/jack is the mount point for rpool/USERDATA/jack_bwcn4u
What is not listed are directories like /etc, so I suspect that Wallen trimmed that listing before he made an image of it.
From what I've studied about ZFS, (and from playing with it a couple years ago), it was/is designed to be used with LOTS of memory, error correcting memory. 32GB or better. Which is probably why you wouldn't want to use this desktop version to keep and maintain a large production database, AND the fact that it is marked experimental. It will probably be available in all Kubuntu releases going forward. And, sooner or later, it will become production quality.
ZFS snapshots vs BTRFS snapshots.
Both are copy-on-write.
Both are initially empty and populate only as the underlying file system changes, eventually taking up as much disk space as the initial dataset or subvolume used. This is one reason why snapshots should be off-loaded onto archive/remote media.
Wallen discusses rolling back to a previous snapshot. In his example a directory in the jack home account was inadvertently deleted. He describes rolling back to a snapshot which contains the directory. What he doesn't mention is that while the directory is restored to what it was when the snapshot was taken, so is every other file and directory in jack's home account. You got the directory back, and what ever it held when its snapshot was made, but you've lost EVERY change that has been made to the home account since that snapshot was taken.
Restoring a system back to a snapshot gains what was lost and loses information that was added after the snapshot was made. This leads to discussions about how often to back up in order to minimize the losses while still keeping as much of the gains as possible. The more recent the snapshot the more gains that are kept. There are trade offs, however. As snapshots begin to fill up, their disk use rises to match the subvolumes they were made from. The older a snapshot is the fuller it becomes and the more disk space it uses. IF everything in the original subvolume is changed then the snapshot becomes identical to the subvolume and you are using twice the disk space. I've read of BTRFS users taking a snapshot every five minutes using a bash script fired with a crontab entry. If both a @root and a @home snapshot are made at the same time, and they should be, that is 192 snapshots per day, 960 per week or 3,840 per month! In the BTRFS subform of this website I discuss what the BTRFS developers say about what the maximum number of snapshots one should take. Taking one every 5 minutes is OK provided that at the end of the day you keep the last one and delete the previous 191, which becomes one backup set per day, five sets per week and twenty sets per month.
Why take a snapshot pair (@root and @home)? Because when adding or removing applications changes are usually made to both the @root and the @home subvolumes. There are some apps that are installed entirely within a user's home account, but for multi-user systems one copy of the application is kept in @root and the @home account GUI contains the user config and data files.
Wallen's deleted directory scenario can be solved very easily in BTRFS without doing a rollback. Merely mount the ROOT FILESYSTEM to /mnt, for example, and then use Dolphin to browse to the directory in the snapshot. Copy and past that directory back into the home account and when it is done umount the ROOT FILESYSTEM. No gains are lost and the deleted directory is restored.
I do not know if one can use that method in a ZFS file system.
The snapshots made in BTRFS are independent of each other. IF I have a series of a set of snapshots, say A, B, C, D and E, where E is the most recent and A is the oldest, and I restore @ and @home from set C, nothing happens to the other snapshots except that any changes in C that are not in A, B D or E is copied to those snapshots. IF I have correctly understood how ZFS operates, then restoring from C eliminates D and E. But,that's a big IF.
BTRFS has very few settings to tweak. ZFS has a LOT of them.
I've experimented with all aspects of BTRFS and "turned it every which way but loose". Yet it has been faultless for me for all the 4+ years I've been using it. Being curious, however, when 20.04 goes golden I'll probably install a version of it in VM and play with ZFS, or, even split my SSD and give it half just to be fair.
Jack Wallen
https://thenewstack.io/how-to-create...-ubuntu-19-10/
A Caveat
Before you dive into this, know that ZFS support in Ubuntu 19.10 is experimental. Although I’ve found it to be incredibly stable, you might think twice about using it in a production environment (until it is no longer listed as “experimental”).
Also, note that ZFS support is currently only offered during the desktop version installation. That doesn’t mean you cannot add support for the filesystem on the server version, but it’s not quite as simple. Because of this, I’ll be demonstrating on the desktop version of Ubuntu 19.10.
Before you dive into this, know that ZFS support in Ubuntu 19.10 is experimental. Although I’ve found it to be incredibly stable, you might think twice about using it in a production environment (until it is no longer listed as “experimental”).
Also, note that ZFS support is currently only offered during the desktop version installation. That doesn’t mean you cannot add support for the filesystem on the server version, but it’s not quite as simple. Because of this, I’ll be demonstrating on the desktop version of Ubuntu 19.10.
With BTRFS two subvolumes are created: @root and @home. ZFS creates what are called "datasets", which are created inside of "pools". During installation two pools are created: bpool and rpool (boot and root). Wallen gives a listing of pools, their datasets and resulting mount points.
Notice that /home/jack is the mount point for rpool/USERDATA/jack_bwcn4u
What is not listed are directories like /etc, so I suspect that Wallen trimmed that listing before he made an image of it.
From what I've studied about ZFS, (and from playing with it a couple years ago), it was/is designed to be used with LOTS of memory, error correcting memory. 32GB or better. Which is probably why you wouldn't want to use this desktop version to keep and maintain a large production database, AND the fact that it is marked experimental. It will probably be available in all Kubuntu releases going forward. And, sooner or later, it will become production quality.
ZFS snapshots vs BTRFS snapshots.
Both are copy-on-write.
Both are initially empty and populate only as the underlying file system changes, eventually taking up as much disk space as the initial dataset or subvolume used. This is one reason why snapshots should be off-loaded onto archive/remote media.
Wallen discusses rolling back to a previous snapshot. In his example a directory in the jack home account was inadvertently deleted. He describes rolling back to a snapshot which contains the directory. What he doesn't mention is that while the directory is restored to what it was when the snapshot was taken, so is every other file and directory in jack's home account. You got the directory back, and what ever it held when its snapshot was made, but you've lost EVERY change that has been made to the home account since that snapshot was taken.
Restoring a system back to a snapshot gains what was lost and loses information that was added after the snapshot was made. This leads to discussions about how often to back up in order to minimize the losses while still keeping as much of the gains as possible. The more recent the snapshot the more gains that are kept. There are trade offs, however. As snapshots begin to fill up, their disk use rises to match the subvolumes they were made from. The older a snapshot is the fuller it becomes and the more disk space it uses. IF everything in the original subvolume is changed then the snapshot becomes identical to the subvolume and you are using twice the disk space. I've read of BTRFS users taking a snapshot every five minutes using a bash script fired with a crontab entry. If both a @root and a @home snapshot are made at the same time, and they should be, that is 192 snapshots per day, 960 per week or 3,840 per month! In the BTRFS subform of this website I discuss what the BTRFS developers say about what the maximum number of snapshots one should take. Taking one every 5 minutes is OK provided that at the end of the day you keep the last one and delete the previous 191, which becomes one backup set per day, five sets per week and twenty sets per month.
Why take a snapshot pair (@root and @home)? Because when adding or removing applications changes are usually made to both the @root and the @home subvolumes. There are some apps that are installed entirely within a user's home account, but for multi-user systems one copy of the application is kept in @root and the @home account GUI contains the user config and data files.
Wallen's deleted directory scenario can be solved very easily in BTRFS without doing a rollback. Merely mount the ROOT FILESYSTEM to /mnt, for example, and then use Dolphin to browse to the directory in the snapshot. Copy and past that directory back into the home account and when it is done umount the ROOT FILESYSTEM. No gains are lost and the deleted directory is restored.
I do not know if one can use that method in a ZFS file system.
The snapshots made in BTRFS are independent of each other. IF I have a series of a set of snapshots, say A, B, C, D and E, where E is the most recent and A is the oldest, and I restore @ and @home from set C, nothing happens to the other snapshots except that any changes in C that are not in A, B D or E is copied to those snapshots. IF I have correctly understood how ZFS operates, then restoring from C eliminates D and E. But,that's a big IF.
BTRFS has very few settings to tweak. ZFS has a LOT of them.
I've experimented with all aspects of BTRFS and "turned it every which way but loose". Yet it has been faultless for me for all the 4+ years I've been using it. Being curious, however, when 20.04 goes golden I'll probably install a version of it in VM and play with ZFS, or, even split my SSD and give it half just to be fair.