RFE: ZFS support

[danielkza]

It would be nice if ZFS filesystems running through FUSE or ZFSOnLinux were supported, in addition to BTRFS and LVM.

[danielkza]

I would be willing to try and do this myself, but it would be nice if someone more familiar with the project could answer a few questions to me first.

• Is it acceptable to use commands instead of a library or IOCTLs to do snapshot control? Unfortunately there is no common established API between all the ZFS implementations.
• ZFS snapshots don't really work like BTRFS where they automatically end up as visible subvolumes. Is that assumption intrinsic to how snapper works? They can be mounted manually, or viewed through the .zfs special directory, but it's structure doesn't match snapper's, and IIRC needs a special pool option set.

[aschnell]

That's great to hear. To answer your questions:

• It is acceptable to use commands instead of ioctl as long as it's secure (LVM code does so).

  Secure here means that a user who can modify the subvolume of which snapshots are made cannot cause snapper (running as root) to do harmful things, e.g. via symbolic links cause snapper to compare files outside the subvolume during comparing snapshots.

  For that reason snapper always checks the permissions on .snapshots and uses system calls working on file descriptor (e.g. openat).

• For LVM the snapshots are also not visible unless mounted. Snapper has code to mount them when needed.

[hoconnor2]

Hi Daniel,

Just thought I'd drop a quick line and see if you had a chance to look into things a bit more with regards to adding ZFS snapshot functionality to the snapper app? That would be incredibly useful to add a slick gui interface. Perhaps something along the lines of FreeNAS looks, but inside of snapper?

[danielkza]

I started an attempt at this a while ago. My initial idea would be using
libzfs, but I ran into issues with different ZFS implementations in the
limited testing I could do. So I suppose going through the zfs command
could be a better path.

I'll do another take in the coming days and report my findings, but
unfortunately, my free time is somewhat sparse ATM. I gladly accept any
suggestions or help in the matter.

Em qui, 6 de ago de 2015 01:12, hoconnor2 notifications@github.com
escreveu:

Hi Daniel,

Just thought I'd drop a quick line and see if you had a chance to look
into things a bit more with regards to adding ZFS snapshot functionality to
the snapper app? That would be incredibly useful to add a slick gui
interface. Perhaps something along the lines of FreeNAS looks, but inside
of snapper?

—
Reply to this email directly or view it on GitHub
#145 (comment).

[darkbasic]

Any news on this?

[ghost]

Bump

[mailinglists35]

I started an attempt at this a while ago. My initial idea would be using
libzfs, but I ran into issues with different ZFS implementations in the
limited testing I could do. So I suppose going through the zfs command
could be a better path

are there any improvements two years later in libzfs?
I'd be happy even if you limited support to only latest released version

[DocMAX]

nobody seems to be interested, the are all on btrfs...

[beren12]

…trying to recover their data?

j/k looking for a simple auto snapshot manager that can work with samba's plugin for windows previous versions, with zfs.

[darkbasic]

Btrfs isn't suitable for VMs, supporting ZFS would be awesome.

[mainframe]

+1

[mumblepins]

So I made an initial version of Snapper with ZFS; it at least passes the testsuite, and seems to work. It can be found on the feature/zfs branch here.

It uses the zfs binary as the front end. The calls are generally simple enough, and it seemed easier.

Notes:

• ZFS on Linux doesn't have ACLs enabled by default. Right now that causes some issues with some of the comparison tests of snapper, but it works fine if ACLs are enabled on the volume.
• ZFS snapshots are the whole volume or nothing. I couldn't figure out a way to exclude a .snapshot directory, so instead snapper makes a subvolume that stores the .snapshot directory. If anyone has a better idea, I'm open to changes.
• ZFS automatically has a hidden folder in the root of each volume that contains the snapshots (.zfs/snapshot). I'm using symlinks from .snapper/1/snapshot --> .zfs/snapshot/snapper-1. Oh yeah, snapshots are called snapper-# . I've put some stubs in the code for potentially using either bind mounts to this point or using the legacy mounting system. zfs mount doesn't like to mount snapshots, and really, there's not much reason to.
• There's also a stub where I was going to monitor the zpool get freeing stat as a substitute for the sync command. Kinda busy with lots of other things though, so if anyone else wants to implement it, be my guest.

Let me know if it works for you! I'd highly suggest trying it in a VM at first though...

[mailinglists35]

I've put some stubs in the code for potentially using either bind mounts to this point or using the legacy mounting system. zfs mount doesn't like to mount snapshots

On all zfs-on-linux systems I've used since 2012, entering the .zfs/snapshot/snapshotname directory will automount it, then when last handle is closed, the directory will unmount automatically. this is entirely managed by zfs. you simply access it, and that's it.

[mumblepins]

Yeah, I know that ZFS automounts to the .zfs directory. However, symlinks can cause problems sometimes so I was thinking that alternative mounting strategies may be appreciated. There has to be some sort of the mount/link/etc. to the actual ZFS snapshot directory in order to store snapshot metadata, as the .zfs directory is read-only.