zfs cmd syntax wrong - cannot work

[chymian]

this seems to be a long stand bug.
the internal cmd used by podman to check a ZFS dataset/fs has a wrong syntax and must always error – was mentioned already 3 years ago.

there is no such parameter like fs in zfs fs …

Context:

rootless:

podman system reset
Error: configure storage: cannot find root filesystem dataz/home/guenter/.local/share/containers: exit status 1: 
"/usr/bin/zfs fs list -rHp -t filesystem -o name,origin,used,available,mountpoint,compression,type,volsize,quota,referenced,written,logicalused,usedbydataset dataz/home/guenter/.local/share/containers" => cannot open 'dataz/home/guenter/.local/share/containers': dataset does not exist

and removing the erroneous fs

/usr/bin/zfs  list -rHp -t filesystem -o name,origin,used,available,mountpoint,compression,type,volsize,quota,referenced,written,logicalused,usedbydataset dataz/home/guenter/.local/share/containers
dataz/home/guenter/.local/share/containers      -       1748750336      2220284936192   /home/guenter/.local/share/containers   zstd    filesystem      -       0       339968  339968  1783496704      339968
dataz/home/guenter/.local/share/containers/podman       -       204800  2220284936192   /home/guenter/.local/share/containers/podman    zstd    filesystem      -       0       204800  204800  71168   204800
dataz/home/guenter/.local/share/containers/podman-desktop       -       1747963904      2220284936192   /home/guenter/.local/share/containers/podman-desktop    zstd    filesystem      -       0       1747963904      1747963904      1783099904      1747963904
dataz/home/guenter/.local/share/containers/storage      -       241664  2220284936192   /home/guenter/.local/share/containers/storage   zstd    filesystem      -       0       241664  241664  88576   241664

works!

lsb_release --all
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux trixie/sid
Release:        n/a
Codename:       trixie

zfs version
  zfs-2.2.5-1
  zfs-kmod-2.2.5-1

---

the command being generated is wrong.

/sbin/zfs fs create -o mountpoint=legacy rpool/podman/2653d992f4ef2bfd27f94db643...

...can't work. The command should be...

/sbin/zfs create -o mountpoint=legacy rpool/podman/2653d992f4ef2bfd27f94db643815aa567240c3773...

Originally posted by @awhileback in containers/podman#11415 (comment)

[Luap99]

Contributions welcome but none of the core maintainers is working on the zfs driver.
We are mostly focusing on overlayfs and vfs.

[chymian]

@Luap99 , thanks for taking the time to answer

unfortunately, I'm no a dev. (if so, I would have long fixed that culprit)

none of the core maintainers is working on the zfs driver.

I did read that excuse in old issues 3-4 years ago as well.

I have a Q for you:
you provide a zfs driver with your software, but deny to fix it? why?

either disable it or fix it. maybe it would be a good idea to put one of the core maintainers on a zfs-workstation.
since it's the most stable and flexible and battle proofed and feature rich FS out there, which I found in the last 40 Years…

no offense meant, but I don't understand that kind of policy.
and what feature will be (not-) handled next?
this raises strategical questions about the use and reliability in future!

[Luap99]

It is not an excuse just a fact. Just because something doesn't work doesn't mean a maintainer is required to fix it. There are thousand of issues/features we could work on so yes in general maintainers need to decide what they do work on. And there doesn't seem to be anyone on the core team that particular cares about ZFS. The core team behind Podman and related tools are all employed by Red Hat and zfs is not only not supported by Red Hat, it isn't even in the upstream linux kernel so expecting a maintainer to use ZFS doesn't make much sense.

This is a FOSS project and anyone can contribute so if someone care about zfs they can submit fixes and we are willing to merge them. If you cannot do that you could pay someone else to do it.

Zfs was added at one point because someone cared about it and it seems to be working for the most part, system reset is a feature that generally isn't used by a lot of people so removing it just because of that doesn't make much sense either as that will break all the existing users of the zfs driver.

Most importantly the zfs driver is used on freebsd as I understand to run containers with podman there.
Maybe @dfr cares about zfs driver issues as he maintains/works on the freebsd code?

[dfr]

I do care about the zfs driver since it is the most efficient storage option on FreeBSD at the moment. I'm not sure exactly what is going on here since podman storage reset seems to be working for me on FreeBSD but I can look into it.

[dfr]

So far I haven't been able to reproduce the problem with rootful containers on FreeBSD. I suspect that rootless on Linux may be part of the issue - I need to build a suitable test VM to check that.

[dfr]

@chymian can you post some details of your setup, including os and podman version - so far I'm unable to reproduce your problem on either Linux or FreeBSD.

[chymian]

hello @dfr ,
sorry for late reply, private life needed some attendance.

@chymian can you post some details of your setup, including os and podman version - so far I'm unable to reproduce your problem on either Linux or FreeBSD.

OS: debian trixie/testing
kernel: 6.9.12-amd64
ZFS: zfs-2.2.5-1
zfs-kmod-2.2.5-1
podman: version 5.2.2

it works for rootful containers without pbls.
but for user - aka. rootless containers, the compiled cmd-line is false:
see the example in my opening post. the fs in the constructed cmd is erroneous (and reminds me more on a btrfs cmd-line then a zfs cmd.)
again: we are only talking about user/rootless setup here!