I put my ZFS scripts whatever I had ChatGPT regurgitate in a github repo.
I wrote the scripts for me and this isn’t my day job (I’m a journalist/data scientist nowadays), so there are some ugly things that were done wrong/improperly, but the scripts work. For example zfs_diff does NOT interpret all the states (just the main ones) and the arg at the end should be a command line switch like -n 2, etc. forgive me. if you want to do a PR on my code, I’d be happy to merge it in!
Or maybe there is a truenas community github repo for stuff like this??
Here’s the readme:
Truenas zfs scripts
These are handy truenas and ZFS scripts to do things such as:
system_config_save: make truenas config backups automatically
zfs_diff: (using the API) to compare current with any past snapshot
zfs mv: rename zfs dataset or zvol (similar to mv)
tcp_params_set: triple the bandwidth on a single stream
zfs_backup: Uses zfs send to create a backup file of certain datasets
zvol_backup: Uses zfs send to create a backup file of just my zVols
seatbelts: Fasten before big change. Release when done. Don’t keep them on long because you can’t do certain operations with seatbelts on. Allows you to roll back a pool, NOT truenas config changes.
def zfs_mv(datasets, destination):
zfs = libzfs.ZFS()
# Get the pool name from the current working directory
cwd = os.getcwd()
pool_name = cwd.split(os.sep)[-1]
# Ensure the destination is relative to the pool root
destination = f"{pool_name}/{destination}"
for dataset in datasets:
# Create the full path relative to the pool name
source = f"{pool_name}/{dataset}"
dest = f"{destination}/{os.path.basename(dataset)}"
print(f"Renaming {source} to {dest}")
try:
zfs.get_dataset(source).rename(dest)
except libzfs.ZFSException as e:
print(f"Error renaming {source} to {dest}: {e}", file=sys.stderr)
sys.exit(1)
This seems inferior to just using the zfs rename command. Additionally, it makes assumptions about the cwd being the target pool and the relationship between the pool name and the cwd. I’m concerned that someone using it may break their truenas configuration in fun and exciting ways. This bypasses our APIs and so users will have to potentially manually fix all shares / other configuration pointing to the old datasets.
Note if you carefully review available APIs for libzfs (not using chatgpt to do the research) you will see that there is a function to convert a given path to a ZFS dataset handle.
That said, paths should never be used for scripts performing ZFS changes because datasets may be unmounted and you can mistakenly rename / delete the wrong thing.
Offering code is nice. If you have put any real effort into it and got something decent.
Telling ChatGPT or some other LLM to regurgitate something with a given goal in mind and yeeting it onto the forum without, as it sounds like, any sort of meaningful review, perhaps not even a cursory test… Well, that’s scummy on multiple levels:
How can you claim ownership?
How can you claim any sort of usefulness? My first reaction was “why is there an apparent reimplementation of zfs rename in here?”. @awalkerix went to the trouble of looking at it, and I thank him for saving me the time.
If you have not even read the relevant documentation, how can you claim to know what this even does?
You’re being at the least very unclear (and at most downright dishonest) about the origin of these scripts.
By your own admission, whatever time and effort you invested in these didn’t include review of the ZFS docs.
Perhaps as a result of the above, some of the scripts are completely redundant (as others have pointed out, there’s a zfs rename commmand to rename/move datasets, so there’s no apparent reason for zfs_mv to exist, even if it didn’t make dangerous assumptions; I likewise wonder what benefit you saw in having a script as a wrapper around zpool checkpoint), while others just don’t do what you say they do (zvol_backup does not, in fact, create a backup file; it just creates snapshots of your zvols). tcp_params_set, even assuming the params in question were sensible (of which I’m skeptical; “triple the bandwidth on a single stream” is at beast a vague description of what it does), should be replaced by appropriate sysctl settings in the TrueNAS UI.
A lower-level concern, but a concern nonetheless: Some of the scripts contain hardcoded paths which make them unsuitable for anyone else’s system without editing.
In order to get it to work, I had to go to the documentation to teach ChatGPT how to use the python library calls.
So saying that I didn’t reference the documentation is simply is not true.
And I stated upfront that it was written for my use only.
I have used all of these scripts on my system sucessfully. They were not written for general purpose use, but can be easily edited for other configurations.
Sure, there are hard coded paths because when I wrote the scripts, my goal was to solve my own problems, not write a general purpose tool which would take more time. The zfs_mv script is problematic which I discovered after the post, but all of the scripts work.
You bear some responsibility when you share scripts.
I get that everything is essentially “use at your own risk”, but the opening post comes off as “here are some handy scripts for ZFS and TrueNAS”.
Had you put a disclaimer (preferably in bold) from the start, you wouldn’t be met with this level of criticism.
Secondly, scripts are much different than guides (which use standard commands and APIs). If you’re sharing a script, you need to more seriously take into consideration the caveats and risks involved. Whereas, a guide is meant to invite the user to “try this out on your own” without relying on straight-up copy+paste or “run this script on your system, maybe edit some stuff, whatever”.
I don’t just provide a script that will use mbuffer + netcat to bypass SSH for low-powered systems. I walk the user through it with enough information for them to hopefully “learn” something on their own time.
If I had just provided a script for weak-cpu-replications.sh, you can bet I would write in big bold letters warning the user not to run the script, and to review it heavily; and I would also share with them how/why I took the approach I did.
