1: I say 1.5 because there is only one false value, but it has 2 idiomatic meanings: nil (equivalent to python's None) and the empty list.
Except, it seems this is BSD-licensed, so I'm not sure how that would work in the kernel (which is GPLv2).
But I'm surprised this is possible without a specification - how can you test a filesystem through hexdumps? The effects of some operations are going to pretty far-reaching, surely?
And thanks for the Borges callout.
Original comment: I could swear this was actually the standard practice for writing an implementation of an unknown file format or interface without infringing on copyright. But I don't remember the term for it.
EDIT: Ninjad because I left the reply in a tab without posting.
That PDF says ”Unless otherwise licensed, use of this software is authorized pursuant to the terms of the license found at: http://developers.sun.com/berkeley_license.html”*. That link is broken, but it seems that’s Berkeley license (whatever that means for a specification, and for which variant?)
According to http://open-zfs.org/wiki/Developer_resources, its outdated, but still useful.
I think I would use that, rather than spend months diffing disk images.
This is the greatest thing ever. I wish I could just write code for the fun of it. Every time I wonder whether people will use it and give up before I even get started.
https://github.com/jaysoffian/eap_proxy
This was a really simple project but tickled all my fancies: Python, low-level, networking, reverse engineering, system administration.
Just do it! Who cares if people use it?
Alternatively, contribute something to some open source project you use. I’ve done that too. Just small stuff here and there but that’ll guarantee someone uses your code if that’s what’s important to you. It only takes 39 commits to get on this page:
https://github.com/git/git/graphs/contributors
:-)
The readme literally answers this..
Edit: of course not. This is actually just it’s just a ZFS user-facing ”front-end”, not a ZFS implementation.
This project is cool not because you're going to run the Python in your kernel today, but because someone can use it as a documented reference implementation of all of the data structures and transactions that is not covered by the CDDL, so another implementation based on this can live in the Linux kernel without problem.
Not taking anything away from the work that the author has done though. It's a nice project. I just think a little pragmatism is needed before we get carried away with the ZFS GPL comments.
[1] https://blogs.oracle.com/solaris/zfs-under-gplv2-already-exi...
note that the issues are entirely different from those with a kernel implementation since you aren't having to think about page cache et all.
I know you from ICV - we used to hang out online on the forums and IRC.
Nice work on this project, I'm looking forward to diving into the codebase!
ICV was the name of the forum for the book, now defunct (icodeviruses.com)
https://www.amazon.com/1337-h4x0r-h4ndb00k-tapeworm/dp/06723...
Thanks for sharing though. Maybe could be useful in making a suite of zfs inspection tools?
Is the OP here? How difficult would it be creat a zfs reshaping tool, allowing for the offline expansion of a vdev?