Transitioning from porting to release mode

[Bjoern Kahl]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Dear All,

this mail is triggered by Lund's "ZFS binary releases, installs,
etc. Discuss!" [1], and split off my other reply to keep different
thoughts in different threads.

(If you are impatience, jump down to the section "Next steps".)


- - - - - - - - Where To Go From Here - - - - - - -

As said [2], I am really happy to see the progress, but I am torn about
the question of when and how we should go public.

You, Lund, have achieved a lot of functionality and we should share
this to a larger audience.

On the other side, hacking up ("hacking" in its positive sense!) a
running code is one thing, long-term maintainability and responsible
release policy is another thing. Especially in Kernel space and even
more in file systems, where people store their invaluable data, way to
often without a backup strategy.

I tried to keep up with your commits and review code changes as they
happen, but you proved yourself to be to productive. :-)

But from what I have seen (and partially commented on) I have serious
concerns switching to regular "mainstream" binary releases. I think of
the current state more as a technology preview then as a release
candidate.

Let me list the more important concerns:

- The current handling of pipes is an ugly hack. In my opinion, it is
not maintainable across releases.

- Hacks in libzfs to get the list of file system for unmount (issue 16)

- The current approach to solve the "mutex_enter: locking against
myself" panics. I am not convinced this isn't allowing race
conditions.

- Apparent incompatibility with ZEVO, which may (or may not) indicate
inconsistencies in the on-disk format (may be ZEVOs fault, needs to
be checked).

All in all, the current code is perfectly fine for a technology
preview, as is the way how it came about.


But for a long-term maintainable release, I strongly suggest to take a
step back.

- The current code is a wild mixture of at least three code lines,
bolted together on a "what runs, that runs" base. Fine for
understanding the challenges and quickly producing a test version.

- I have the feeling, the real interaction of VFS and ZPL and its SA
code is not fully understood.

- ZoL gave us a quick start, but it is itself a port of Illumos code,
to a kernel different from MacOSX/Darwin and Solaris/Illumos.

- SPL, coming from ZoL, is designed for Linux and now adapted to
MacOSX. Not the most direct approach.


Looking at the commit history, I would suggest to leave the current
code behind and do a fresh clone. This fresh clone could then be
carefully re-ported, using all the insights gained in the past three
months, and avoiding short-cuts taken in the rapid "make it run" phase.

The goal should be, to arrive at a well understood and maintainable
port. This includes to document in commit messages and even more in
mailing list posts the design decisions taken on the way.


Talking about re-cloning, I am even not sure if ZoL is the right
upstream, because each time we pull in an upstream update, we would
need to undo all the Linux specific changes in ZoL.

ZoL (and FreeBSD) have changed to code layout, which doesn't make
direct updates from Illumos easier.


Last not least, and that is a real *show-stopper* for me, ZoL comes
with SPL which is GPL-licensed. There is *no* legal way, to have CDDL
and GPL in the same binary.


No matter which way we go, we will need a clean replacement for SPL.
Which is, why I deliberately kept my fingers and my eyes out of SPL
as much as I could. To be able to create a not-GPL-tainted Darwin
portability layer, when needed.

Obviously, every one is free to choose his/her stand on the GPL issue,
but as a project we are not free. We must adhere to any and all
copyright rules.


Taking ZoL for rapid exploration of what is needed to glue a recent
ZFS to MacOSX was a valuable approach. Having a running version which
passes most tests in just three months is a success. But now we need
to look forward.

I have a few ideas for how to fix various issues listed above, but
this mail is already to long, so lets discuss individual technical
issues in separate threads. Here only a few keywords:

- Upstream: Keep ZoL or switch to Illumos. Consider the Open ZFS
project http://2013.eurobsdcon.org/eurobsdcon-2013/talks/#AhrensMatuska

- Memory management: See if and what parts need to be wired, and what
parts can be swappable kernel memory. Think about "last resort"
memory pools.

- mmap & Co: Should parts of ARC be bundled with the UBC? (This is
probably a long-term question to be addressed *after* the first
public release.)

- Untangle OSX vn_xxx and vnode_xxx calls as much as possible from the
znode code. The gold standard here is the CDDL part of ZEVO, which
shows how clean one can get the znode.c

- Further explore Will's osx-vfs-wrappers approach (merged in zfs-osx
master). May conflict with "Untangle OSXvn_xxx and vnode_xxx calls"

- make sure eject and export work and allow unload of the kext. Don't
panic on unexpected vdev detach (i.e. "pulling the plug" of an
external enclosure).

- support for all architectures and OSX releases (PPC, I386, X86_64,
Leopard to Maverick)

(As said, above topics should be discussed in individual threads.)


- - - - - - - Next steps - - - - - - -

- Make a source App from current code, as a technology preview.
I.e. package the source into an App, which will compile it on the
users machine and then offer options to test it, similar to Lund's
"Stage 1" in [1]. Of course, the App will only work on machines
which have XCode installed.

- Decide on the needed refactoring and re-clone, including the
upstream to use.

- Created a GPL free porting infrastructure. Must be done by someone
not involved in the current SPL.

- Move over the basic functionality from current technology preview,
to the new clone, taking care to not introduce licensing issues or
suspicious code.

- Make first Beta as installer package.



Best regards

Björn

[1] https://groups.google.com/forum/#!topic/maczfs-devel/Y-74JcIzCiw
[2] "ZFS binary releases, installs, etc. Discuss!" 2013-06-23 02:32 CEST
- --
| Bjoern Kahl +++ Siegburg +++ Germany |
| "googlelogin@-my-domain-" +++ www.bjoern-kahl.de |
| Languages: German, English, Ancient Latin (a bit :-)) |
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQCVAgUBUcZBx1sDv2ib9OLFAQKrBgP/d4ZSdSTpCWzamjcfg8LtyQsmyP8xH2X5
0oxViZhbciNUmltcNM9w8Qc15wB7gCVE0skVbATOX9EvdIJxs2Toe0WELRAxCZvB
fyO4itKA+q3GeBvINYkihZOPQiIbuGWj2q9s0GpxC678u2vB+Q7FKcV5aWXfXbCR
O7hx+tRP9vc=
=sYKI
-----END PGP SIGNATURE-----

[Will Andrews]

Thanks for your thoughts Bjoern.

I wholeheartedly agree that the approach taken thus far has involved
many unmaintainable hacks. But yes, ones that demonstrate solutions
for given problems, and are valuable for that reason.

The original FreeBSD port, back in 2005, initially involved a similar
approach, but has (somewhat slowly) over time merged into Illumos.
The VFS layer in FreeBSD, for example, evolved to largely take the
shape that I proposed in the osx-vfs-wrappers branch.

I would like to strongly encourage MacZFS to join and participate in
the new Open ZFS initiative, which from what I understand is planned
to kick off this fall. I certainly plan to participate for FreeBSD.
In the interim, I've been working to push OS-independent changes to
Illumos, and my first proposed changes were committed to illumos-gate
on June 11. In my mind, that is the best way to ensure forward
maintainability for every ZFS implementation, including MacZFS.

As part of Open ZFS, we should explore developing a portability layer
that makes it easy for each port to implement local versions without
modifying the upstream files, and modifying ZFS itself to enable
sharing OS-independent code in a similar fashion.

For example, I've been working on ZVOL portability improvements
towards these goals, so that it's implemented in two parts: an
OS-independent backend, and an OS-dependent frontend, which can be
implemented in separate files. Again, this is another example of the
paradigm successfully applied to the VFS layer, and it can be applied
to many other parts of ZFS too. One of the challenges, of course, is
going to be finding ways to agree on reasonable, stable interfaces
that don't penalize platforms.

The size of ZFS being what it is, I think that not only will it be
vital to collaborate with other ports on OS-independent code, it will
also be vital to adopt and share a comprehensive test suite. Ztest is
great for what it is, but it's only one piece of the testing needed.
The STF test suite will likely be a focus for Open ZFS as well, and it
will complement ztest in the area of integration/functional-level
testing. And MacZFS should adopt that as a gatekeeper for updated
releases as well.

On Sat, Jun 22, 2013 at 6:31 PM, Bjoern Kahl <googl...@bjoern-kahl.de> wrote:
> - Apparent incompatibility with ZEVO, which may (or may not) indicate
> inconsistencies in the on-disk format (may be ZEVOs fault, needs to
> be checked).

This is exactly the sort of thing that would be targeted & tested by
full deployment of ztest and the STF suite on MacZFS, for validating
on-disk compatibility.

> - ZoL gave us a quick start, but it is itself a port of Illumos code,
> to a kernel different from MacOSX/Darwin and Solaris/Illumos.

I view using ZoL as more of a way to quickly bootstrap the build, and
also the portability layer. Darwin would need a version of SPL either
way. And likely many of the same things that are already in SPL.
Again, a shared portability layer in which a port can pick and choose
what it needs, would benefit every port. The build infrastructure is
likely going to be a contentious issue...

> Looking at the commit history, I would suggest to leave the current
> code behind and do a fresh clone. This fresh clone could then be
> carefully re-ported, using all the insights gained in the past three
> months, and avoiding short-cuts taken in the rapid "make it run" phase.
>
> The goal should be, to arrive at a well understood and maintainable
> port. This includes to document in commit messages and even more in
> mailing list posts the design decisions taken on the way.

I'm not sure leaving zfs-osx behind entirely is the way to go. It
could probably be cleaned up as is, at least enough to resolve the
pain points when trying to bring in upstream changes. Whether that's
more or less work, I'm not sure. The previous MacZFS ports were
treated in a similar fashion for zfs-osx.

> Talking about re-cloning, I am even not sure if ZoL is the right
> upstream, because each time we pull in an upstream update, we would
> need to undo all the Linux specific changes in ZoL.
>
> ZoL (and FreeBSD) have changed to code layout, which doesn't make
> direct updates from Illumos easier.

These will very likely be early topics for Open ZFS, and I agree that
even FreeBSD's organization could use some cleaning up.

> - mmap & Co: Should parts of ARC be bundled with the UBC? (This is
> probably a long-term question to be addressed *after* the first
> public release.)

This is also a subject of discussion for the FreeBSD ZFS community;
that is, merging ARC properly with the VM layer. I think it will take
a long time to accomplish and should definitely be left for later.

Thanks!
--Will.

[Daniel Bethe]

>No matter which way we go, we will need a clean replacement for SPL.
>Which is, why I deliberately kept my fingers and my eyes out of SPL
>as much as I could.  To be able to create a not-GPL-tainted Darwin
>portability layer, when needed.
>
>Obviously, every one is free to choose his/her stand on the GPL issue,
>but as a project we are not free.  We must adhere to any and all
>copyright rules.

Hi Bjoern.  I'm confused here.  Why are you thinking that there's a problem with the GPL vs. CDDL?  The only issue raised by GPL vs. CDDL is that of the distribution of the files from the publisher to the end user.  The GPL content and the CDDL content are each in totally separate files.  As far as I understand it, they're in totally separate source code repositories right now, yielding separate kernel extensions.  If what I just said is as correct as it plainly seems to be, then there is no legal issue.  What the user does with their own files upon receipt of them, is entirely their own concern.

So help me understand what the problem is, whether it's an actual legal theory or whether it's just a personal concern arising from your personal stake in your high reputation and such.  Thanks!

[Bjoern Kahl]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Daniel,
hi All!

Am 23.06.13 05:43, schrieb Daniel Bethe:

Of course I am not a lawyer, but my understanding of the debate
regarding ZFS on Linux was and is, that a binary ZFS kernel module
can not be legally distributed, because it would link to the GPL'd
kernel, and GPL does not allow distributions of binaries that are the
result of linking or otherwise combining GPL and non-GPL code, if such
non-GPL code has incompatible rules for modifying and redistributing
it.

That's the difference between GPL and LGPL. The LGPL explicitly
allows the covered code to be linked (but not otherwise combined) with
non-GPL'd code.

Both, GPL and LGPL exempt operating system libraries from this
restrictions, so you can for example compile and distribute a GPL'd
program for proprietary platforms. But this exemption does not apply
if the resulting product is meant as part or extension of the
operating system.

To my not-a-lawyer understanding, this means we can not distribute the
ZFS kext from the new experimental branch, because producing the kext
involves linking the ZFS core kext with the SPL kext, i.e. linking
CDDL with GPL.

Just my understanding. And to honest, in this particular case I
prefer to err on the safe side, i.e. get rid of any GPL traces.
Which should not be so difficult.


Best

Björn

- --
| Bjoern Kahl +++ Siegburg +++ Germany |
| "googlelogin@-my-domain-" +++ www.bjoern-kahl.de |
| Languages: German, English, Ancient Latin (a bit :-)) |
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQCVAgUBUcbO71sDv2ib9OLFAQK65QP+IsArlSKG1QoIgUTpM59MuQX/CWCtr7Ib
0Arx7PAB9Qob/8BJR8x1wpiFFRUccYD4p8le5VXJcvLB0w35HAktHTp++1mOBoPu
/LF74ho0MFB/mo2gGy2Nv4XF8MMFBGDWe1zUJQPl4e3rReh7dE5ToLYsxQ/bZ4UC
XPiCmBZBGAY=
=Rqid
-----END PGP SIGNATURE-----

[Daniel Bethe]

> Of course I am not a lawyer, but my understanding of the debate
> regarding ZFS on Linux was and is, that a binary ZFS kernel module
> can not be legally distributed, because it would link to the GPL'd
> kernel, and GPL does not allow distributions of binaries that are the
> result of linking or otherwise combining GPL and non-GPL code, if such
> non-GPL code has incompatible rules for modifying and redistributing
> it.

But like I said, they're not linked.  Why are you saying they're linked?  They're two totally different repositories, resulting in two totally different files, not unlike how Nvidia handles it.  Isn't that right?

I understand wanting to be safe, but still, there are a lot of people out there who are totally and obviously wrong about a lot of things.  :)

[lun...@lundman.net]

Hello!

Let me try to break down each of your comments and attempt to come up with my views As always, this is
just my opinion so let's not take anything too seriously.

My motivation stems from that I want ZFS for All Platforms, at any cost. So I would have been just fine running ZEVO, if it wasn't for
the fact that it is missing features I consider crucial. I would be happy with a stolen copy made my Chinese Sweatshops! And I
did look at MacZFS, but alas at version=8, is missing even more features than ZEVO, and not really easy to port forward.

So I was forced to make my own attempt.

Even though I joke about it, I will explore how a VFS layer could be done on Windows after this.

With that in mind, let me fire my volley in this discussion!

 On the other side, hacking up ("hacking" in its positive sense!) a
 running code is one thing, long-term maintainability and responsible
 release policy is another thing.  Especially in Kernel space and even
 more in file systems, where people store their invaluable data, way to
 often without a backup strategy.

This was definitely a hack, and a one-off. Consider it an experiment. I wanted to
see if "compiling" was putting OS X users off testing it, or convenience, or what. So as
an attempt to get a poll of possible users, and possible 'news buzz' generated, it resulted
in exactly 2 download, and 3 upvotes. I don't think of it as something negative, it just means
I should expect to do most, if not all, myself. But I was expecting that from the start. Any
help is a pleasant surprise.


 

 I tried to keep up with your commits and review code changes as they
 happen, but you proved yourself to be to productive. :-)

I find it a little odd that you would attempt it. You will be spending all day reading other people's work, rather
than contributing yourself.  Once we have a stable platform, and maintaining stability is primary, I can understand.
Still, I'm not complaining, if you want to do that, then do that. :)
 

 

 - The current handling of pipes is an ugly hack.  In my opinion, it is
   not maintainable across releases.

On this we will most likely always disagree. ZFS send/recv with pipe support is a must, and the command line juggle suggested, to work
around the lack of pipes, really needs to be cleansed with fire. I personally feel the mistake is actually that of Apple's. Happily providing API
calls for files, and Network streams, but forgetting pipes.

At the moment, this works from 10.6 to 10.9. It is possible that 10.10 will break, and if so, another solution will be needed.
Which goes pretty much for every single call to the kernel.  ZEVO also calls the same function, and even though ZEVO version
does not work on Mavericks, it is not related to this. Although, they clearly found some other way to link than using
Evan's special KEXT.

Now, if you wish to make a PEDANTIC preprocessor macro, to compile the kext without the 2 calls, that would be acceptable. This way you
can ensure your version is pristine. 

 

 - Hacks in libzfs to get the list of file system for unmount (issue 16)

I agree completely. If only someone fixed it instead of doing code reviews all day! :)
 

 - The current approach to solve the "mutex_enter: locking against
   myself" panics.  I am not convinced this isn't allowing race
   conditions.

One of the differences in getting a new vnode on the BSD platforms, is that calling vnode_create() can start a reclaim process. FreeBSD's solutions to this
is to pre-allocate the vnode before entering the lock. This solution does not work on OS X. Apple was a little lean with the vnode API here.
Now, as the reclaim process is always (currently) run as the current-thread, we can handle it pretty cleanly by checking for lock ownership. If Apple
ever changes it to a separate reclaim thread, we will definitely need a different solution.

ZEVO's approach is to not-reclaim-znodes during this time (by checking ownership), but throw them on a reclaim list. Spawn a reclaim thread to release them 'later'. If you inspect
the error messages of ZEVO (and the forum panics) they also have issues of the reclaim thread being full etc. Not convinced that this is a better solution.


 

 - Apparent incompatibility with ZEVO, which may (or may not) indicate
   inconsistencies in the on-disk format (may be ZEVOs fault, needs to
   be checked).

Already fixed, you are about 4 days behind. It was missing XATTR, and getdirattr calls. More in this below.

 

 - The current code is a wild mixture of at least three code lines,
   bolted together on a "what runs, that runs" base.  Fine for
   understanding the challenges and quickly producing a test version.

In a sense. My first "phase" was to get something to work, as quickly as possible. This was to tell me, if *I* could
do this at all. Naturally, you don't want to spend too long on something that you might not be capable of doing.

After some weeks, it became clear that I could probably do it.

At this point, Will's had done his much cleaner VNOP wrapper layer. I ditched the hastily throw together work, and started again.

I took "the 5" interface source files (zfs_vfsops, zfs_znode, zfs_dir, zfs_acl, zfs_fuid) directly from FreeBSD. I made sure to not
put any MacZFS work into it, then ported everything again into zfs_vnop_osx and zfs_vnop_osx_lib as was started by Will.

One of the worst ideas of the original MacZFS is the z_phys nodes inside the z_node, as some sort of "persistent" information store.
I strongly believe that much of the stability of my first attempt (as most likely, with taking MacZFS forward) stems from this. All those
issues went away when I re-ported the FreeBSD work into Will's wrappers.

This is also why XATTR, mmap and getdirattr took so long to go back into the development version, as it needed to be re-ported to not use
z_phys, and generally be inspected.  And those 3 functions in particular, still are not quite correct. (mmap)

If you diff, for example, zfs_vnops.c with FreeBSD, you will find only irrelevant changes. I feel very good about how clean this current
version is. But if you are not as familiar with the current sources, it will feel unknown and hacky, I am sure.

I am grateful that Will did the VNOP wrappers, as it turned out to be the best thing ever.


 

 - I have the feeling, the real interaction of VFS and ZPL and its SA
   code is not fully understood.

I would think this stems from unfamiliarity with the particular sources, and you should simply familiarise yourself
with it. To use your words, "I feel" this is an issue you have, and not an issue with the project..

 

 - ZoL gave us a quick start, but it is itself a port of Illumos code,
   to a kernel different from MacOSX/Darwin and Solaris/Illumos.

If only I had 100 yen for every time someone asks me why I ported ZOL. :)  When I started with ZOL, essentially all I did
was take the autoconf build environment, and the header locations. ZOL has a *strong* separation between ZFS and SPL.
And again, a *strong* separation between SPL and the kernel. All in a self contained autoconf set of directories.

FreeBSD, IllumOS, do not. It is ingrained with the kernel build process, using direct kernel calls, rather than being forced through
SPL. (ZOL does have an exception to this, the zvol.c stuff is Linux kernel, rather than using SPL in between. They should
fix this)

So, autoconf, directory layout, headers, and if you will, repository history, comes from ZOL. The core ZFS is the same for any platform.
The "5 files" that interface with VFS, is from FreeBSD. Almost untouched. Which is almost untouched from IllumOS. That is the whole
point with SPL (and FreeBSD's 'opensolaris' modules). The ZFS sources remain mostly untouched. There is nothing ZOL about it.

Having said that, because it is connected to ZOL's repository, when we are ready, I can git merge in the new features, like lz4. If we
were based on IllumOS or FreeBSD, this would be a manual process. With ZOL it *could* be a 'mostly automatic' situation.

Naturally, if OpenZFS happens, with its own repository, that would be most excellent.
 

 - SPL, coming from ZoL, is designed for Linux and now adapted to
   MacOSX.  Not the most direct approach.

Not at all. SPL autoconf comes from ZOL. The source and headers come from MacZFS. The rest I wrote.

 

 Looking at the commit history, I would suggest to leave the current
 code behind and do a fresh clone.  This fresh clone could then be
 carefully re-ported, using all the insights gained in the past three
 months, and avoiding short-cuts taken in the rapid "make it run" phase.

I have already done a fresh clone, and I re-ported things 'much slower'. I understand you like to
work with ... 'glacial pace'.. perhaps, and you could certainly still do that.

 Last not least, and that is a real *show-stopper* for me, ZoL comes
 with SPL which is GPL-licensed.  There is *no* legal way, to have CDDL
 and GPL in the same binary.

It concerns me that you would rather 'not have ZFS at all' than having 'ZFS with the possibility of GPL'. That
you would essentially risk the death of a project, over something so irrelevant.

BUT, this is my view. I do not care at all about licenses. But others do, so be it.

As I have already stated, everything in SPL came from MacZFS, or written by me directly. None of the sources came from ZOL. Now, you are
most likely jumping up and down right now as there is probably some LICENSE file, or Headers that start with GPL in there. This
is because *I don't care about licenses*. I did not bother deleting, or updating the "header headers". Simply pasted in the code I needed.

The license of SPL is whatever MacZFS was, and whatever I say my code is. So for those that care about licenses, please
make it say whatever makes you happy. I give you permission to make my code whatever license you desire.

That aside, The US government funded the Lawrence Livermore National Laboratory to port ZFS to Linux, and
their lawyers decided that the licensing of GPL and CDDL is not an issue. Or at least, when kept in SPL and ZFS modules.

Do you believe you know better than them?

 

 - Upstream: Keep ZoL or switch to Illumos.  Consider the Open ZFS
   project http://2013.eurobsdcon.org/eurobsdcon-2013/talks/#AhrensMatuska

ZFS sources are just ZFS sources. All glue is kept in SPL and "opensolaris" modules. The upstream repository is irrelevant.
However, if OpenZFS gets its own repository, I am all for making it our upstream.

 

 - Memory management: See if and what parts need to be wired, and what
   parts can be swappable kernel memory.  Think about "last resort"
   memory pools.

This definitely needs work. We currently run out quite easily. Mainly because we only keep a total tally of allocations, when OS X
keeps a separate list for each size (256, 512, 1024, ...) and we often run out of 512 or 1024 first. We might need to
do more kernel linking hacks to gain access to the memory allocators so we can detect if we are about to run out. (hah! I only
said that for the effect. But we do need to do something here).

 

 - mmap & Co: Should parts of ARC be bundled with the UBC?  (This is
   probably a long-term question to be addressed *after* the first
   public release.)

That would be nice.

 

 - Untangle OSX vn_xxx and vnode_xxx calls as much as possible from the
   znode code.  The gold standard here is the CDDL part of ZEVO, which
   shows how clean one can get the znode.c

Our (current) znode is cleaner than ZEVOs. Unless you refer to the headers and the "ZEVO_SPECIFIC_FIELDS_HERE;" mess... brrr.

 

 - Further explore Will's osx-vfs-wrappers approach (merged in zfs-osx
   master).  May conflict with "Untangle OSXvn_xxx and vnode_xxx calls"

Already in, and working beautifully.
 

 - make sure eject and export work and allow unload of the kext.  Don't
   panic on unexpected vdev detach (i.e. "pulling the plug" of an
   external enclosure).

Never heard of this panic. But I haven't tried it either.
 

 - support for all architectures and OSX releases (PPC, I386, X86_64,
   Leopard to Maverick)

I support 32bit/64bit, 10.6 to 10.9+. But PPC and earlier I consider irrelevant. Hell, Apple has already cut support of them off.
We might even have to let go of 32bit realistically, but my home machine is still stuck on 10.6.

 

Please ask me to clarify something if I am not entirely clear. English is my third language after all, as it is to many others in here.
I think many things we can compromise on just fine, which is why we are having this discussion.

Lund



 

 

[Matthew Ahrens]

Will, thanks for your post and your support for Open ZFS.  To me, this is the idea that all open source ZFS implementations can work together to make ZFS an even better filesystem than it already is.  There are many ways we can accomplish that, starting with this dialogue.  One of my main goals with Open ZFS is to make it easier for all platforms to benefit from the ongoing improvements being made to ZFS on each individual platform, by making it easier to pull changes between the various platforms.

I think I'm pretty much on the same page as Will here.  A few comments inline below:

On Sat, Jun 22, 2013 at 6:59 PM, Will Andrews <wi...@freebsd.org> wrote:

Thanks for your thoughts Bjoern.

I wholeheartedly agree that the approach taken thus far has involved
many unmaintainable hacks.  But yes, ones that demonstrate solutions
for given problems, and are valuable for that reason.

The original FreeBSD port, back in 2005, initially involved a similar
approach, but has (somewhat slowly) over time merged into Illumos.
The VFS layer in FreeBSD, for example, evolved to largely take the
shape that I proposed in the osx-vfs-wrappers branch.

I would like to strongly encourage MacZFS to join and participate in
the new Open ZFS initiative, which from what I understand is planned
to kick off this fall.  I certainly plan to participate for FreeBSD.
In the interim, I've been working to push OS-independent changes to
Illumos, and my first proposed changes were committed to illumos-gate
on June 11.  In my mind, that is the best way to ensure forward
maintainability for every ZFS implementation, including MacZFS.

Thanks again for your work in this area; I know that it was not easy get your changes committed to illumos.  I'm working to streamlining this process, simplifying the steps to build and test ZFS on illumos.

 

As part of Open ZFS, we should explore developing a portability layer
that makes it easy for each port to implement local versions without
modifying the upstream files, and modifying ZFS itself to enable
sharing OS-independent code in a similar fashion.

I definitely agree, and I would invite the MacZFS developers to participate in discussions on the details of how we should modify common ZFS code to make it easier to share OS-independent code.  For example, the Linux port has removed all C99 code, and has a much smaller stack size than illumos, so it uses kmem_alloc() instead of allocating things on the stack.  I don't know if MacZFS also has these restrictions, but it has inherited the maintenance burden associated with them.  We could decide on a common set of coding guidelines that works for everyone.  This would make it much easier for people to pull /push commits between platforms.

 

For example, I've been working on ZVOL portability improvements
towards these goals, so that it's implemented in two parts: an
OS-independent backend, and an OS-dependent frontend, which can be
implemented in separate files.  Again, this is another example of the
paradigm successfully applied to the VFS layer, and it can be applied
to many other parts of ZFS too.  One of the challenges, of course, is
going to be finding ways to agree on reasonable, stable interfaces
that don't penalize platforms.

Very cool; looking forward to those changes.

 

The size of ZFS being what it is, I think that not only will it be
vital to collaborate with other ports on OS-independent code, it will
also be vital to adopt and share a comprehensive test suite.  Ztest is
great for what it is, but it's only one piece of the testing needed.
The STF test suite will likely be a focus for Open ZFS as well, and it
will complement ztest in the area of integration/functional-level
testing.  And MacZFS should adopt that as a gatekeeper for updated
releases as well.

I agree.  We are also working on migrating the STF zfs tests to the new, simpler TestRunner framework which is part of the illumos-gate.  Hopefully TestRunner will be easier to get running on MacOS than STF.  For details, see: https://github.com/illumos/illumos-gate/tree/master/usr/src/test

Yes, I'd like to figure out how the ZFS code can be more similar on every platform, so that it's easier to pull and push commits between platforms.  This will likely involve some code changes and cleaning on every platform, to bring them more into alignment.

 

>  - mmap & Co: Should parts of ARC be bundled with the UBC?  (This is
>    probably a long-term question to be addressed *after* the first
>    public release.)

This is also a subject of discussion for the FreeBSD ZFS community;
that is, merging ARC properly with the VM layer.  I think it will take
a long time to accomplish and should definitely be left for later.

Thanks!
--Will.

--matt 

[Bjoern Kahl]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Lund,
hi All,

thanks for the detailed answer. Before I answer back in-line below,
I'd like to share a few general observations and comments.

It is obvious to me, that we (Lund and Björn) have very different
views on a few crucial things. Which is fine for me, as long as we
are aware of it and can agree to disagree.

The most obvious one is the question of development style. Pushed to
extremes, there are to schools: (a) Develop with the compiler running,
i.e. "code, compile, tweak" in a loop, until it compiles, then tweak
until it does the job. Don't care about design or internal structure.
And (b) design on paper, develop on paper, debug (i.e. review) on
paper. When done, once compile the code and repeat all the tests done
on paper with the real thing - no surprise should show up.

In their extreme, both approaches are impractical, but I am clearly
positioned far towards (b), and I assume you are somewhere towards (a).
Maybe at the 1/4 milestone on the path from (a) to (b)?
I am probably somewhere between the 2/3 and 7/8 milestones.


The second point are intellectual property rights. While I am
convinced, that the current IPR regulations in Europe and elsewhere
badly need an upgrade to move from the late 19th to the early 21st
century, I'll enforce them wherever I can.


Am 24.06.13 03:10, schrieb lun...@lundman.net:

> My motivation stems from that I want ZFS for All Platforms, at any
> cost. So I would have been just fine running ZEVO, if it wasn't for
> the fact that it is missing features I consider crucial.

Out of curiosity: Which features?

> I would be happy with a stolen copy made my Chinese Sweatshops!

A statement your are free to make as an independent individual. But a
hazardous opinion to voice for any (public) project.

> And I did look at MacZFS, but alas at version=8, is missing even
> more features than ZEVO, and not really easy to port forward.
>
> So I was forced to make my own attempt.

See below at (1).

> Even though I joke about it, I will explore how a VFS layer could
> be done on Windows after this.

Seriously? If you really manage a working port of ZFS to a recent
Windows, it would probably mean eternal fame -- and a whole new
storage experience for millions of users!

> With that in mind, let me fire my volley in this discussion!
>
>> On the other side, hacking up ("hacking" in its positive sense!)
>> a running code is one thing, long-term maintainability and
>> responsible release policy is another thing. Especially in
>> Kernel space and even more in file systems, where people store
>> their invaluable data, way to often without a backup strategy.
>>
>>
> This was definitely a hack, and a one-off. Consider it an
> experiment. I wanted to see if "compiling" was putting OS X users
> off testing it, or convenience, or what. So as an attempt to get a
> poll of possible users, and possible 'news buzz' generated, it
> resulted in exactly 2 download, and 3 upvotes. I don't think of it
> as something negative, it just means I should expect to do most,
> if not all, myself. But I was expecting that from the start. Any
> help is a pleasant surprise.

I am not sure if your comment just targets the "testing situation", or
includes the development before. Assuming the latter, I'd loved to
help and contribute, but by just pushing forward, without much
discussion on how you envision the port, how to deal with various
design choices to take on the way, you made helping pretty hard.

(1)

Silently looking around and then starting one's own thing without
making much words is certainly a possible way to attack the unsure
future of ZEVO and the really slow progress of MacZFS. -- Often seen
in the Open Source world and so far a successful one.

(About development approach, see also (2) and (3) below.)

>> I tried to keep up with your commits and review code changes as
>> they happen, but you proved yourself to be to productive. :-)
>>
> I find it a little odd that you would attempt it. You will be
> spending all day reading other people's work, rather than
> contributing yourself.

To contribute something that fits, I first need to understand what you
are doing, and which design you are following.

> Once we have a stable platform, and maintaining stability is
> primary, I can understand.

:-) Sorry, but I had to smile here. I have heard variations of that
line probably a thousand times from my students. And as many times I
answered back: No, stability and security has to be designed in from
the beginning. You can't bolt it on later.

> Still, I'm not complaining, if you want to do that, then do that.
> :)

< off-topic >

First design, then code and constant peer review is just my second
nature. In my professional life, among other things I teach software
development for autonomous robots. Our machines directly interact
with people, without fences or other physical protection, so safety is
a primary concern. In that life, not a single line of code should
ever end up on the machines without being peer reviewed and clean,
readable code with documented design is a must.

Of course, ZFS for Mac is a different being, but at the same time I
can't teach one style while in class and apply the opposite style on
my (public) spare time projects.

< /off-topic >

>> - The current handling of pipes is an ugly hack. In my opinion,
>> it is not maintainable across releases.
>>
>>
> On this we will most likely always disagree. ZFS send/recv with
> pipe support is a must, and the command line juggle suggested, to
> work around the lack of pipes, really needs to be cleansed with
> fire. I personally feel the mistake is actually that of Apple's.
> Happily providing API calls for files, and Network streams, but
> forgetting pipes.
>
> At the moment, this works from 10.6 to 10.9. It is possible that
> 10.10 will break, and if so, another solution will be needed.
> Which goes pretty much for every single call to the kernel. ZEVO
> also calls the same function, and even though ZEVO version does not
> work on Mavericks, it is not related to this. Although, they
> clearly found some other way to link than using Evan's special
> KEXT.
>
> Now, if you wish to make a PEDANTIC preprocessor macro, to compile
> the kext without the 2 calls, that would be acceptable. This way
> you can ensure your version is pristine.

Nothing to add here. We disagree.

>> - The current approach to solve the "mutex_enter: locking
>> against myself" panics. I am not convinced this isn't allowing
>> race conditions.
>>
>>
> One of the differences in getting a new vnode on the BSD
> platforms, is that calling vnode_create() can start a reclaim
> process. FreeBSD's solutions to this is to pre-allocate the vnode
> before entering the lock. This solution does not work on OS X.
> Apple was a little lean with the vnode API here.

Agreed on Apple being a bit lean with the vnode API.

> Now, as the reclaim process is always (currently) run as the
> current-thread, we can handle it pretty cleanly by checking for
> lock ownership. If Apple ever changes it to a separate reclaim
> thread, we will definitely need a different solution.
>
> ZEVO's approach is to not-reclaim-znodes during this time (by
> checking ownership), but throw them on a reclaim list. Spawn a
> reclaim thread to release them 'later'. If you inspect the error
> messages of ZEVO (and the forum panics) they also have issues of
> the reclaim thread being full etc. Not convinced that this is a
> better solution.

I do not have a definite idea either. With pre-allocation unavailable,
it is a hard problem. Especially as we are not allowed to reject a
reclaim call (the Darwin API documentation says, that return with an
error from vnop_reclaim will panic).

Something I'd like to explore is to move the real vnode interaction
entirely out of the lock protected ZFS core. Do everything only on
znodes, and if that succeeded, then in a second step update the VFS'
view, rolling back the znode side if the VFS update fails. Of course,
this would probably require yet another level of locking outside the
existing layers, and will also be hard to get race-free.
:-) Once more the "principle of the preservation of the hard work" at
work: No matter what you try to ease a job, at some point you have to
do the heavy lifting.

>> - Apparent incompatibility with ZEVO, which may (or may not)
>> indicate inconsistencies in the on-disk format (may be ZEVOs
>> fault, needs to be checked).
>>
>>
> Already fixed, you are about 4 days behind. It was missing XATTR,
> and getdirattr calls. More in this below.

You are /really/ fast.

>>
>> - The current code is a wild mixture of at least three code
>> lines, bolted together on a "what runs, that runs" base. Fine
>> for understanding the challenges and quickly producing a test
>> version.
>>
>>
> In a sense. My first "phase" was to get something to work, as
> quickly as possible. This was to tell me, if *I* could do this at
> all. Naturally, you don't want to spend too long on something that
> you might not be capable of doing.
>
> After some weeks, it became clear that I could probably do it.
>
> At this point, Will's had done his much cleaner VNOP wrapper
> layer. I ditched the hastily throw together work, and started
> again.
>
> I took "the 5" interface source files (zfs_vfsops, zfs_znode,
> zfs_dir, zfs_acl, zfs_fuid) directly from FreeBSD. I made sure to
> not put any MacZFS work into it, then ported everything again into
> zfs_vnop_osx and zfs_vnop_osx_lib as was started by Will.
>
> One of the worst ideas of the original MacZFS is the z_phys nodes
> inside the z_node, as some sort of "persistent" information store.
> I strongly believe that much of the stability of my first attempt
> (as most likely, with taking MacZFS forward) stems from this. All
> those issues went away when I re-ported the FreeBSD work into
> Will's wrappers.

??? Having z_phys referenced in the znode is original Solaris design,
as early as October 2005.

Side note: You did meant "instability" above, not "stability"?

> This is also why XATTR, mmap and getdirattr took so long to go
> back into the development version, as it needed to be re-ported to
> not use z_phys, and generally be inspected. And those 3 functions
> in particular, still are not quite correct. (mmap)
>
> If you diff, for example, zfs_vnops.c with FreeBSD, you will find
> only irrelevant changes. I feel very good about how clean this
> current version is. But if you are not as familiar with the
> current sources, it will feel unknown and hacky, I am sure.
>
> I am grateful that Will did the VNOP wrappers, as it turned out to
> be the best thing ever.

Good and informative write-up of the current state. Clarifies several
things.

>> - I have the feeling, the real interaction of VFS and ZPL and
>> its SA code is not fully understood.
>>
>>
> I would think this stems from unfamiliarity with the particular
> sources, and you should simply familiarise yourself with it. To
> use your words, "I feel" this is an issue you have, and not an
> issue with the project..

(2)

It is an impression I have, and impressions can be false. I would
have preferred to read something about it before it was pulled in,
maybe a reference to some old FreeBSD discussion. Again, just adding
a larger code blob, even if just moved from elsewhere, without arguing
why it is right, is something I am not used to.

>> - ZoL gave us a quick start, but it is itself a port of Illumos
>> code, to a kernel different from MacOSX/Darwin and
>> Solaris/Illumos.
>>
>
> If only I had 100 yen for every time someone asks me why I ported
> ZOL. :) When I started with ZOL, essentially all I did was take
> the autoconf build environment, and the header locations. ZOL has
> a *strong* separation between ZFS and SPL. And again, a *strong*
> separation between SPL and the kernel. All in a self contained
> autoconf set of directories.
>
> FreeBSD, IllumOS, do not. It is ingrained with the kernel build
> process, using direct kernel calls, rather than being forced
> through SPL. (ZOL does have an exception to this, the zvol.c stuff
> is Linux kernel, rather than using SPL in between. They should fix
> this)
>
> So, autoconf, directory layout, headers, and if you will,
> repository history, comes from ZOL. The core ZFS is the same for
> any platform. The "5 files" that interface with VFS, is from
> FreeBSD. Almost untouched. Which is almost untouched from IllumOS.
> That is the whole point with SPL (and FreeBSD's 'opensolaris'
> modules). The ZFS sources remain mostly untouched. There is
> nothing ZOL about it.

Having a separated porting layer is in my view the single advantage of
ZoL compared to IllumOS.

> Having said that, because it is connected to ZOL's repository,
> when we are ready, I can git merge in the new features, like lz4.
> If we were based on IllumOS or FreeBSD, this would be a manual
> process. With ZOL it *could* be a 'mostly automatic' situation.

We have had scripts to automatically extract and merge the ZFS related
changes from OpenSolaris repository. They haven't been used for some
time, but in principle should work with IllumOS.

Of course, it is more convenient to let other people (ZoL) do that for
us.

> Naturally, if OpenZFS happens, with its own repository, that would
> be most excellent.

At least one more thing we agree on.

>>
>> - SPL, coming from ZoL, is designed for Linux and now adapted to
>> MacOSX. Not the most direct approach.
>>
>>
> Not at all. SPL autoconf comes from ZOL. The source and headers
> come from MacZFS. The rest I wrote.
>
>
>> Looking at the commit history, I would suggest to leave the
>> current code behind and do a fresh clone. This fresh clone
>> could then be carefully re-ported, using all the insights gained
>> in the past three months, and avoiding short-cuts taken in the
>> rapid "make it run" phase.
>>
>>
> I have already done a fresh clone, and I re-ported things 'much
> slower'. I understand you like to work with ... 'glacial pace'..
> perhaps, and you could certainly still do that.

:-) I like the term "glacial pace", I haven't heard it before.
Although it is less a "like to" then a "have only the weekends" kind
of story.

> Last not least, and that is a real *show-stopper* for me, ZoL
> comes
>
>> with SPL which is GPL-licensed. There is *no* legal way, to
>> have CDDL and GPL in the same binary.
>>
>>
> It concerns me that you would rather 'not have ZFS at all' than
> having 'ZFS with the possibility of GPL'. That you would
> essentially risk the death of a project, over something so
> irrelevant.

It is not "not have ZFS at all" vs. "ZFS with the possibility of GPL".

MacZFS is ZFS without GPL. ZEVO is ZFS without GPL. It is more
respecting the law and following a clean approach. For example, one
could think of using FreeBSD and its 'opensolaris' module to speed up
MacZFS. Something actually discussed last year, before Alex went AWOL.

> BUT, this is my view. I do not care at all about licenses. But
> others do, so be it.
>
> As I have already stated, everything in SPL came from MacZFS, or
> written by me directly. None of the sources came from ZOL. Now,
> you are most likely jumping up and down right now as there is
> probably some LICENSE file, or Headers that start with GPL in
> there. This is because *I don't care about licenses*. I did not
> bother deleting, or updating the "header headers". Simply pasted in
> the code I needed.

Actually, there are 168 files with GPL header in the zfs-osx / spl
repository.

> The license of SPL is whatever MacZFS was, and whatever I say my
> code is. So for those that care about licenses, please make it say
> whatever makes you happy. I give you permission to make my code
> whatever license you desire.
>
> That aside, The US government funded the Lawrence Livermore
> National Laboratory to port ZFS to Linux, and their lawyers
> decided that the licensing of GPL and CDDL is not an issue. Or at
> least, when kept in SPL and ZFS modules.
>
> Do you believe you know better than them?

They are lawyers, I am not. So by definition, they are more
knowledgeable in this field. Nevertheless, LLNL avoided the whole
problem, by never releasing a binary kernel module. They just release
source code, which in any case is not a problem, since the GPL, as far
as I understand it, is only concerned about distributing a singe
derived work, i.e. a binary.

>>
>> - Upstream: Keep ZoL or switch to Illumos. Consider the Open
>> ZFS project
>> http://2013.eurobsdcon.org/eurobsdcon-2013/talks/#AhrensMatuska
>>
>>
> ZFS sources are just ZFS sources. All glue is kept in SPL and
> "opensolaris" modules. The upstream repository is irrelevant.
> However, if OpenZFS gets its own repository, I am all for making
> it our upstream.

Open ZFS, once established, is certainly the repository I would
consider first.

>> - Memory management: See if and what parts need to be wired, and
>> what parts can be swappable kernel memory. Think about "last
>> resort" memory pools.
>>
>>
> This definitely needs work. We currently run out quite easily.
> Mainly because we only keep a total tally of allocations, when OS X
> keeps a separate list for each size (256, 512, 1024, ...) and we
> often run out of 512 or 1024 first. We might need to do more
> kernel linking hacks to gain access to the memory allocators so we
> can detect if we are about to run out. (hah! I only said that for
> the effect. But we do need to do something here).

Currently, I don't know how to best approach the memory management.
Something to research and then decide.

>> - mmap & Co: Should parts of ARC be bundled with the UBC? (This
>> is probably a long-term question to be addressed *after* the
>> first public release.)
>>
>>
> That would be nice.
>
>
>
>> - Untangle OSX vn_xxx and vnode_xxx calls as much as possible
>> from the znode code. The gold standard here is the CDDL part of
>> ZEVO, which shows how clean one can get the znode.c
>>
>>
> Our (current) znode is cleaner than ZEVOs. Unless you refer to the
> headers and the "ZEVO_SPECIFIC_FIELDS_HERE;" mess... brrr.

Nice to read, and another thing that happened silently. I am some days
behind in following what you did. Well, probably more some weeks.

>> - Further explore Will's osx-vfs-wrappers approach (merged in
>> zfs-osx master). May conflict with "Untangle OSXvn_xxx and
>> vnode_xxx calls"
>>
>
> Already in, and working beautifully.
>
>
>>
>> - make sure eject and export work and allow unload of the kext.
>> Don't panic on unexpected vdev detach (i.e. "pulling the plug"
>> of an external enclosure).
>>
>
> Never heard of this panic. But I haven't tried it either.
>
>
>>
>> - support for all architectures and OSX releases (PPC, I386,
>> X86_64, Leopard to Maverick)
>>
>>
> I support 32bit/64bit, 10.6 to 10.9+. But PPC and earlier I
> consider irrelevant. Hell, Apple has already cut support of them
> off. We might even have to let go of 32bit realistically, but my
> home machine is still stuck on 10.6.

As are mine. I have no intention to update to Lino or Mountain Lion.
From what I saw so far, Snow Leopard is the last usable release of
Mac OSX, before Apple started to iOS-ify the Desktop.

Regarding PPC, there are quite some old PPC-based Xserve out there and
still in production.

> Please ask me to clarify something if I am not entirely clear.
> English is my third language after all, as it is to many others in
> here.

I had no problems following your English. To me, as a non-native, it
looks like pretty high standard.

> I think many things we can compromise on just fine, which is why
> we are having this discussion.

I tried to answer all the concerns. The red line for me is ignoring
licenses.

(3)

A big concern for me is long-term maintainability and stability.

I may be mistaken, but my impression is, that the existing MacZFS user
base is rather conservative, valuing stability over features, but of
course happy for each new feature we can deliver. Many in the
community use MacZFS in production, some in their business. This puts
a lot of responsibility on the project maintainers.


Best regards

Björn

- --
| Bjoern Kahl +++ Siegburg +++ Germany |
| "googlelogin@-my-domain-" +++ www.bjoern-kahl.de |
| Languages: German, English, Ancient Latin (a bit :-)) |
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQCVAgUBUctW+1sDv2ib9OLFAQL39QQAt2hp8/NS6X9ER5VcHcSHtXtG7xWPG0Zd
f16nBG39a6v6/e5pb8hmRAUBZe9+InFzPP/VrpTTLvhFTmswTipL9D/7nTptM7yv
vFa0qH+VpyLlwHnLF8BEGwe7HVcO8UR2rPI6709yU4o7qJALWyuJvQnBiW3z6XXA
9QZyaIrscEw=
=MIzv
-----END PGP SIGNATURE-----

[Jorgen Lundman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

Actually this was a very useful email.

Much of my license frustration stems from dealing with .. hmm, "linux
fanboys", who will some sort of have a seizure, or "brain tilting",
whenever they hear ZFS and license, and some of that spilled over onto
you and your valid question regarding the current state.

I was unaware that you are in the academic world, indeed I am the product
of academia myself. Although the conversation about the disconnect
between the world of academia, and the "real world", is better savoured
over a pint in the pub one day, but it has given me an insight to your
position.


As we both know, the entirety of porting ZFS to a platform is too big for
one developer. You've carried this torch for a very long time, and know
how hard it is to find time to do the things you want. Or if not time,
enthusiasm, or any of the other hurdles.

This is why I am "here" as well - in the hopes of assistance. Ultimately,
'others' will be taking this project further, hopefully with me in the
picture, but maybe not.

Though my experience tells me 'if *I* do not do it, it does not get done'
- - which, sad as it is, is remarkably common. Certainly once projects hits
the 4 months mark (and are not funded) they have a high risk of stalling.

>> My motivation stems from that I want ZFS for All Platforms, at any
>> cost. So I would have been just fine running ZEVO, if it wasn't for
>> the fact that it is missing features I consider crucial.
>
> Out of curiosity: Which features?

Ah hmm let's see, I wanted ZFS-Volumes, encryption, lz4, dedup. I have
already assisted with the first 2, and the latter pair I get for free
from ZOL.

>> Even though I joke about it, I will explore how a VFS layer could be
>> done on Windows after this.
>
> Seriously? If you really manage a working port of ZFS to a recent
> Windows, it would probably mean eternal fame -- and a whole new
> storage experience for millions of users!

There is already ext2 port to Windows, using the IFS kit, which should be
an excellent starting point. It'd probably be hard, maybe too hard (for
me). But it would still be interesting to have a look at. Any day that I
learn something new, is a good day :)

>> Once we have a stable platform, and maintaining stability is
>> primary, I can understand.
>
> :-) Sorry, but I had to smile here. I have heard variations of that
> line probably a thousand times from my students. And as many times I
> answered back: No, stability and security has to be designed in from
> the beginning. You can't bolt it on later.

Yes I can understand. If you consider this one of your student's project,
you have to start your considerations from 0 and the student has to
convince you that it is well thought out, designed and stable.

However I am starting with the *assumption* (and assumptions can be
dangerous) that core-ZFS *is* well-thought out, solid design, researched,
extensively tested and stable.

I made the same assumption about Darwin. (Although, the lacking pipe API
sure makes that .. interesting).

So as long as I don't change any fundamental ways that the 'core of ZFS'
works (and a hard Avocado seed it is indeed), and simply make the
interface, the glue layer, between the two systems, the *whole* will
still be solid.

Well, that's the theory... eventually 'in practise' will show up to the
party, fashionably late as usual.


This is a poor yard stick indeed, but as quick insight, checking the
number of #ifdef for __APPLE__ (or __DARWIN__ on ZEVO) we have

MacZFS: 843
ZEVO: 284
osx.zfs: 118

I think we are doing well, but maybe we can be even cleaner!

> Side note: You did meant "instability" above, not "stability"?

Yes, I did indeed.

> Actually, there are 168 files with GPL header in the zfs-osx / spl
> repository.
>

Not sure my subtle hint is working here :), so I can take a half-day to
fix the license in SPL. But nobody has offered which license they prefer.
I assume then we are ok with CDDL? Someone will have to stand up and give
a definite answer here, rather than a suggestion. I can make it happen
after that.

> source code, which in any case is not a problem, since the GPL, as
> far as I understand it, is only concerned about distributing a singe
> derived work, i.e. a binary.
>

They are indeed 2 separate binaries, and could even be separate downloads
if so required. But since SPL is not GPL, we can even look at making it
one binary like ZEVO did.

> I may be mistaken, but my impression is, that the existing MacZFS
> user base is rather conservative, valuing stability over features, but
> of course happy for each new feature we can deliver. Many in the
> community use MacZFS in production, some in their business. This
> puts a lot of responsibility on the project maintainers.

A regular user of Apple product probably does not understand why they
would want ZFS in the first place, so it is most likely a small sub-set
we are dealing with. I think it is still worth doing though.


- --
Jorgen Lundman | <lun...@lundman.net>
Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work)
Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell)
Japan | +81 (0)3 -3375-1767 (home)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/

iEYEARECAAYFAlHLk9AACgkQXZu5ATg1N8RHNgCgul+WwkeI1RgV6AQKzyO35+fF
a9EAoLc0NR72Reepvz1xaSx4Nf2Km8MV
=pG/s
-----END PGP SIGNATURE-----

[Graham Perrin]

On Thursday, 27 June 2013 02:22:24 UTC+1, lun...@lundman.net wrote:

 

… A regular user of Apple product probably does not understand why they would want ZFS in the first place, so it is most likely a small sub-set we are dealing with. I think it is still worth doing though. …

Rewind to parts of the 1990s: many users of regular computers could not understand why a person might want the minority alternative, the Apple. 

Now: many users of HFS Plus will not understand why a person wants the minority alternative, ZFS. 

Picture everything that is, or will be, in and around Open ZFS. Within that picture are individuals and organisations who have been, or will be, in minority positions. Also there's platform diversity with Open ZFS. Some are more popular or widely appreciated than others, but each platform has its own qualities. 

There are diverse approaches to development, testing and review, not all of which can bear fruit when we are at our hungriest. One flavour can not please all palates. 

Licenses remain a thinking point. My occasional flippancy in IRC belies a respect for these things. 

Whatever the nature of the sub-set/minority -- whatever the diversity -- there's certainty that for a significant proportion of Mac users: 

* ZFS will make things better! 

Certainty, and more. To Bjoern, Jorgen, and all others involved: the ZFS thing is most certainly worth doing. 

Keep up the great work, in whatever ways will carry you painlessly past each milestone. The optimist in me knows that there will be happy milestones not tied to four-month marks. We will support you in all possible ways. 

Thanks

Graham

[Dave Abrahams]

On Sunday, June 23, 2013 6:10:55 PM UTC-7, lun...@lundman.net wrote:

At the moment, this works from 10.6 to 10.9. It is possible that 10.10 will break, and if so, another solution will be needed.

Hi,

Any news on 10.10 compatibility?

Thanks,

Dave 

[Daniel Bethe]

At the moment, this works from 10.6 to 10.9. It is possible that 10.10 will break, and if so, another solution will be needed.

Hi,

Any news on 10.10 compatibility?

10.10 doesn't exist!

[jasonbelec]

Been catching up on all this, lots of great points and views. I'll keep my trap shut as I've been lagging in any useful contributions even though I am a major user of MacZFS. I am going through much of what is being worked on as I can to see what I can contribute, although at the speed some of you are pushing stuff out I'm wondering how I'll free up the time to get current much less be useful. Wo is Me.

As for the legal trap, get to a functional release then I can put someone on that and decisions can be made. Nothing ever ends up in the real world as the designer intended, way too many compromises in general.

@Dave, I have a copy for you, send $40 through PayPal and I'll send you a link. ;)