Hacker News new | ask | show | jobs
by 91aintprime 1929 days ago
I feel like it's better to embed the tool in a language, or many community supported languages than embed a programming language in the tool.
2 comments

Per the docs on zfs program:

    The entire script is executed atomically, with no other administrative operations taking effect concurrently. 
Which would be somewhat hard to ensure with an external language.
This just sounds like when the script is run, a lock is taken. It seems like a pretty fast and loose definition of "atomic" (as in, not the ACID sense), as it says below:

     If a fatal error is returned, the channel program may have not executed at all, may have partially executed, or may have fully executed but failed to pass a return value back to userland. 
If an external tool is allowed to acquire this kind of exclusive lock, I don't see the difference.
> If an external tool is allowed to acquire this kind of exclusive lock, I don't see the difference.

That's the whole point, as I understand it. The channel programs are executed in the kernel, in a way that cannot be done by external programs. Some more details here[1].

edit: I also think you should have included the note, which says

Note: ZFS API functions do not generate Fatal Errors when correctly invoked, they return an error code and the channel program continues executing.

So while it's not quite ACID-level, its not as bad as it sounds without that note.

[1]: https://openzfs.org/wiki/Projects/ZFS_Channel_Programs

My feeling is that they're already there with the command line (just look at the filter stuff). Might as well just go all the way and have something sane that's supported all over.