RFE: ZFS support - Githubissues

danielkza commented 9 years ago

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

danielkza commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 https://github.com/openSUSE/snapper/issues/145#issuecomment-128230583.

darkbasic commented 7 years ago

Any news on this?

ghost commented 7 years ago

Bump

mailinglists35 commented 7 years ago

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 commented 7 years ago

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

beren12 commented 6 years ago

…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 commented 6 years ago

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

mainframe commented 6 years ago

+1

mumblepins commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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.

openSUSE / snapper

RFE: ZFS support #145