[Pkg-zfsonlinux-devel] About downstream patches on debian packages from zfsonlinux.org repository.

Wed Aug 24 00:52:40 UTC 2016

On 23/08/16 21:03, Turbo Fredriksson wrote:
> On Aug 23, 2016, at 12:44 PM, Carlos Alberto Lopez Perez wrote:
> 
>> https://etherpad.gnome.org/p/zol-deb-patches
> 
> 
> 7644 debian/patches/PR1099.patch	- iSCSI
> 1410 debian/patches/PR1476.patch	- SMB
> 571 debian/patches/PR2790.patch		- NFS
> 
> These three will never, EVER be accepted! It is also unlikely
> that a replacement for it will EVER come - it requires _A SUBSTANTIAL_
> change and work to both ZED and ZFS! And there is absolutly no
> interest in doing the work from anyone.
> 
> However, I still maintain these and if accepted, I will continue
> to do so. Not that it needs much work, they don't touch anything
> that's ever updated.
> 

If they NEVER will be accepted, then I don't think we should merge them.
I'm not interested in forking the ZoL project, neither in maintaining
forever a set of patches that add some functionality that was rejected
by upstream.

> All three of these have been running in production, not only on
> my own server(s), but also others. Not a huge amount, granted,
> but enough to warrant them "stable".
> 
> 
> The SMB functionality we have in ZoL now is _SERIOUSLY_ (!!!)
> broken and almost never works. I wrote that as a test (my first
> big C project in 10+ years!) and it was accepted somewhat
> prematurely. I then rewrote it in a way that actually works, all
> of the time for everyone! As in, going from USER share to REGISTRY
> shares.
> 
> 
> The current NFS functionality is also quite seriously broken and
> doesn't work at all in several occasions (not even _corner_ cases!).
> 
> 
> And, of course, the iSCSI functionality doesn't exist at all and
> will very likely not be available in upstream in many, many years
> to come.
> 
> 
> I think it would do our users a great disservice not to include these
> three ones!
> 

How many users (in terms of %) actually use those features?

Also, does having support for NFS/SMB/iSCSI built-in inside ZFS allow to
do something that can be done otherwise ? I mean, I deployed many times
iSCSI, NFS and SMB exports on ext3/ext4, which is completely agnostic to
this. I don't see why having the support built-in inside ZFS is _so_
important.

I get that having the support inside ZFS is nice, etc.
But functionality-wise, what it actually provides other than be easier
to manage and more efficient?

> 
> 619 debian/patches/PR1867.patch		- Property Overrides
> 173 debian/patches/PR2668.patch		- zfs receive additions
> 110 debian/patches/PR3238.patch		- zfs unshare additions
> 166 debian/patches/PR3465.patch		- -o feature@<feature>=disable additions
> 
> Meh! Good to have, but I'm not married to the idea to have them in.
> 
> 
> 4881 debian/patches/PR3559.patch	- Refactor SYSV init (Phase 2)
> 543 debian/patches/PR3560.patch		- Refactor SYSV init (Phase 3)
> 425 debian/patches/PR3884.patch		- Refactor systemd
> 
> Very MEH! In my opinion, the whole init/systemd system in ZoL is
> seriously broken and needs serious work. These three is/was supposed
> to get us (ZoL) into the game where downstream don't need to do anything.
> 

Well. I don't think is so broken as you claim. I have been testing the
upstream systemd script and they have worked for me without any problem
so far. Even with ZFS (non rootfs) on top of dm-crypt it worked without
a problem.

I guess they are broken for some specific corner or non-very-standard
cases like #826121.

> These are also things that we (downstream) do much better in this
> regard and do anyway. Shipping broken init/systemd scripts "just because
> it's not in upstream" is IMO ridiculous! We've always created that
> ourself anyway.
> 
> These three PRs was supposed to make sure that wasn't necessary and
> that EVERYONE runs the same code.
> 
> But I don't care enough to fight over this. Want to support broken boot,
> imports, mounts, shares etc, then feel free to use the upstream ones.
> They sure have enough issues regarding that! I (with these patches)
> have had none in the last year! They work, and they work VERY WELL!
> 

Yes, I think is fine to patch the systemd/initramfs scripts to make them
work better on Debian.

Probably upstream don't uses the initramfs scripts as much as we do,
since they seem to test mostly on CentOS/RHEL which I understand use
dracut by default instead of initramfs scripts.

> 
> There is absolutly nothing that dictates that the packages in
> Debian GNU/Linux _must_ be _exactly_ like the ones distributed
> by upstream. Especially if upstream is [seriously] broken or
> lacks [serious] functionality! If we can provide better functionality,
> then that's a win for us!

Granted. But If upstream is so seriously broken, then I very much prefer
to either quit from this team, orphan the package, or request the
removal of it.
I'm pretty sure that I don't want to maintain a package from a seriously
broken upstream. Even more if is something as serious as a filesystem
where any bug can be fatal (data loss, security breach, etc).

But, given that a lot of people (pretty much any non-debian user) seem
to be using what upstream provides in production, I don't think that
your claim of upstream being so broken reflects the reality.

Also I don't think upstream lacks serious functionality. What you see as
a serious functionality it is probably so serious for a tiny fraction of
the user base. Otherwise I don't understand how people are happily using
ZoL on another distros where their packages lack this patches.

Ubuntu is probably where the biggest user base is, since they include
ZFS built-in on the default system. And they are shipping an unpatched
ZoL. Guess how many bugs regarding broken NFS/SMB/iSCSI they got? [1]
Also, given that you can probably provide the same functionality using
traditional tools like NFSv4 /etc/exports, Samba or iscsitarget, makes
this issue much less serious.

Regards.
--------

[1] 1 out of 14: https://bugs.launchpad.net/ubuntu/+source/zfs-linux

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 883 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-zfsonlinux-devel/attachments/20160824/30f9c6fa/attachment.sig>