Hacker News Reader

Uh you are mixing sensible suggestions (ashift=12 as a default, {pool}:{dataset} syntax, though it will be hard to change so late) with very, very opinionated ones, which break use cases you may not be aware of.

Naming pools after hostnames: I have pools on a SAN which can be imported by more than one host.

Weekly scrubs, periodic snapshots, periodic pruning: This is really the job of the OS' scheduler (an equally opinionated view, I admit)

collapsing zpool and zfs commands - sure but why? so you can have zfs -pool XXXX and zfs -volume XXXX?

No recursive datasets? I have use cases where it's very useful.

`zfs list` should show if a dataset is mounted or not, if it is encrypted or not, and if the encryption key is loaded or not: Fully agree!

Don't make me type disk IDs when creating pools: You can address them in 3-4 different ways (by id, by WWN, by label, by sdX etc), and you have to specify in _some_ way which disks you want to go there, so not sure what's the point here.

Store metadata on the disk so ZFS doesn't get confused if I set up a pool with `/dev/sda` and `/dev/sdb` references and then shuffle around the drives: Already happening. Swap a few drives around and import the pool, it will find them.

Some of your suggestions are genuinely OK, at least as defaults, but some indicate you aren't really considering much outside your own usage pattern and needs. ZFS caters to a lot more people than you.

I'm not suggesting zfs itself change. I'd like a porcelain for people with very simple needs where zfs is almost overkill, for people who just want better data integrity and quicker backups on their main machine, for example.

I think zpool is unnecessary as an additional command. For example, `zfs scrub`, `zfs destroy [pool | dataset]`, `zfs add`, `zfs remove` would all have clear meanings. There may be a couple commands that would need explicit disambiguation with a flag like `zfs create`.

I missed completely that you were discussing just a wrapper and not touching the original ZFS. Completely my bad! Obviously some of my objections become quite moot in that light.

> ZFS caters to a lot more people than you.

And under the OP's proposal, those people would continue to ZFS entirely unaffected. The OP wasn't proposing changing the behaviour of ZFS, but rather "wrapping" this defined set into a well-defined recipe which could be used by people who aren't so opinionated.

This "dumbed down wrapper" wouldn't even need to be called ZFS, to avoid confusion. Personally I'd like to propose the name ZzzFS: which is ZFS made so simple you can do it in your sleep...

I like that. I was thinking Zoofus, easy enough for a doofus.

Would also accept EZFS.

> so ZFS doesn't get confused if I set up a pool with `/dev/sda` and `/dev/sdb`

To be fair, that's not ZFS's problem, that is your problem for not keeping up with the times. PBCAK.

For quite some time now, Linux has had fully-qualified references, e.g. : `/dev/disk/by-id/ata-$manufactuer-$serial-$whatever`

That is what you should be using when building your pools.

My problem is that that's a pain to type out. I've read that it's necessary (and other's have said it's not), but it'd be more convenient to just do `mirror /dev/sda /dev/sdb` than `mirror /dev/disk/by-id/ata-WDC_WDBNCE5000PNC_21365M802768 /dev/disk/by-id/ata-Samsung_SSD_850_EVO_500GB_S2RANX0HA52854X`

One and done. One you type it would you can use zfs list|status from there. There is nothing wrong using sda and sdb but if you need to replace a drive In the future it’s just easier with the by-id label.

Working with drive serial numbers is great. I would ban using /dev/sda etc. Nothing like being able to read the sticker on the disk to make sure you pulled the right one. Or that "sda" is actually what you think it is when you're booted from a recovery disk.

Create the pool using `/dev/sda` etc then:

    sudo zpool export tank
    sudo zpool import -d /dev/disk/by-id -aN

the tab key is my friend here.

True, but in ZFS, you don't usually use these names unless you are shoving disks around. In which case it's nice to have an identity on the disk.

Most of your work is a logical naming scheme on top.

Tab complete would not add that much over head in typing... I have never understood the complaint that verbosity is bad. We have systems that enable you to be both verbose and quick, win win...

I believe defining a storage array based on an immutable ID to be far better than the dynamic OS Assigned ID like /dev/sda which may have a total of what 5 key strokes more when using tab complete?

> I've read that it's necessary (and other's have said it's not)

It is not, it's outdated advice that stubbornly persists. Try it yourself if you are not convinced, create a pool using /dev/sdx and change the device order, zfs will still find it, because why wouldn't they just dereference sdx and store UUIDs?

Does that still work if you remove one device while renaming?

Renaming pools is not related.

Specifying devices to `zpool create` as path vs uuid vs partlabel vs partuuid makes absolutely no difference to the end result of what is written to the devices, and never did. ZFS does not rely on device paths to identify vdevs (that would be nuts if you consider ever trying to move pools between machines).

However it used to make a difference to the /etc/zfs/zpool.cache [0] which records the current imported pools for the OS. AFAIU the problem used to be that this cache would inherit device specifications from the zpool import command (or implicit import from a zpool create command), and this is what got people got into trouble when device path enumeration is not deterministic across boots, thus the advice to avoid device paths during zpool create arose, but was only really applicable to zpool import ... This was never a permanent issue for the pool, you could always simply re-import it with UUIDs etc to rebuild the cache in a reliable way.

This was patched way back in 2016, to make sure the cache never uses /dev/sdx alone... Although it's kind of buried in a commit at the end of a semi-related PR [1]:

     Fix 'zpool import' blkid device names

    When importing a pool using the blkid cache only the device
    node path was added to the list of known paths for a device.
    This results in 'zpool import' always using the sdX names
    in preference to the 'path' name stored in the label.

    To fix the issue the blkid import path has been updated to
    add both the 'path', 'devid', and 'devname' names from the
    label to known paths.  Sanity check is done to ensure these
    paths do refer to the same device identified by blkid.

You can cat your zpool.cache and see those three identifiers in the ASCII parts for yourself.

TL;DR you are free to specify devices using /dev/sdx

This is the same problem I mentioned in my other comment, the current quantity of ZFS myths and outdated advice on the web is substantial and takes a lot of navigating or investigating - The best you can do for now is never accept any advice without proof, and test, always test.

[0] https://openzfs.github.io/openzfs-docs/Project%20and%20Commu...

[1] https://github.com/openzfs/zfs/pull/4523/commits/73abf3a8634...

OTOH you have BTRFS where you can use whatever you want, and just find all disks using the filesystem ID to join the array. Works like a charm and you never have to think about it.

ZFS does that too, the top-level comment was just uninformed. You can shuffle your disks around, move them to other machines, and even move the contents to different physical drives and ZFS will still automatically find them all using metadata written to the disks called the "zpool label".

Thanks for the clarification! This makes more sense for a fs as praised as zfs to be that flexible

A lot of these suggestions are heavily opinionated. Which is not necessarily bad, but they seem to mess with existing conventions just for the sake of it (why {pool}:{dataset}?).

> Don't make me name [...] snapshots.

You might like this little tool I wrote: https://github.com/rollcat/zfs-autosnap

You put "zfs-autosnap snap" in cron hourly (or however often you want a snapshot), and "zfs-autosnap gc" in cron daily, and it takes care of maintaining a rolling history of snapshots, per the retention policy.

It's not hard writing simple ZFS command wrappers, feel free to take my code and make your own tools.

Fair point on the {pool}:{dataset} thing. I just don't like that the same {pool} name refers to both a pool of vdevs and the top-level dataset on that pool. It makes it that little bit harder to grok the distinction. Perhaps there's a better way to emphasize that difference.

The distinction is easy. If you're using the 'zpool' binary, you're operating on the pool. If you use the 'zfs' binary, you're operating on the dataset.

Nice, you reminded me of my own incomplete Rust rewrite of the Ruby ZFS snapshot script I wrote about a decade ago, and this bit of yak shaving that ended up derailing me: https://github.com/Freaky/command-limits

I ended up finishing neither, and should pick them back up!

(I snapshot in big chunks with xargs to try to minimise temporal smear - snapshots created in the same `zfs snapshot` command are atomic)

I've read that one of the last task of a blacksmith apprentice is to make all the tools a workaday blacksmith would need to use to blacksmith. IE your last lesson is to make your own anvil, your own hammers, tongs, etc.

At $DAYJOB I wrote a bunch of scripts to mechanize building ZFS arrays for whatever expected deployment I'd imagined on that day. Among the tasks was to make luks encrypted volumes on which to put the zvols, standardize the naming schemes, sane defaults like ashift=12, lz4 compression, etc. (this was well before encryption was part of ZFS; I haven't updated the scripts since to support encryption in zfs since it's not really been a problem this way)

I don't remember many of these flags now, but have a script as reference for documentation, and others on the team don't need to know much about ZFS besides run make-zfs-big-mirror or make-big-zfs-undundant-raid0 and magic happens.

Eventually maybe even that stuff will be automated away by our provisioning, if we ever are in a position to provision systems more than 20 times per year.

Last time I tested performance (~2 years ago), zfs on luks performed better than zfs encrypted datasets, on sequential reads, almost twice as good. This was on particularly slow hard drives.

Not sure why, and I should probably make the test reproducable.

Honestly this is one of the reasons I love ansible. I create scripts while doing it the first time. Then the rest is hitting go and forgetting. The scripts are the documentation, like you said. The hell if I'm remembering all those magic incantations. You only ever will remember what you frequently use, the rest is for off-brain storage.

As others have noted, these are really opinionated suggestions. And while it's perfectly fine to have an opinion, many of these vary between "this isn't the way I'm used to Linux doing it" to the actually objectionable.

The ones I find most personally objectionable:

> - Don't make me name pools or snapshots. Assign pools the name {hostname}-[A-Z]. Name snapshots {pool name}_{datetime created} and give them numerical shortcuts so I never have to type that all out

Not naming pools is just bonkers. You don't create pools often enough to not simply name them.

Re: not naming snapshots, you could use `httm` and `zfs allow` for that[0]:

    $ httm -S .
    httm took a snapshot named: rpool/ROOT/ubuntu_tiebek@snap_2022-12-14-12:31:41_httmSnapFileMount

> - collapse `zpool` and `zfs` into a single command

`zfs` and `zpool` are just immaculate Unix commands, each of which has half a dozen sub commands. One the smartest decisions the ZFS designers made was not giving you a more complicated single administrative command.

> - Provide an obvious way to mount and navigate a snapshot dataset instead of hiding the snapshot filesystem in a hidden directory

Again -- you can do this very easily via `zfs mount`, but you'll have to trust me that a stable virtual interface also makes it very easy to search for all file versions, something which is much more difficult to achieve with btrfs, et. al. See again `httm` [1].

[0]: https://kimono-koans.github.io/opinionated-guide/#dynamic-sn... [1]: https://github.com/kimono-koans/httm

> I would love to have a dumbed down wrapper that made the common case dead-simple.

TrueNAS

This. ZFS for Dummies == TrueNAS.

It's interesting; I'm the kind of person who feels uncomfortable using something without understanding the shape of the stack underneath it. A magic black box is anathema; I want to know how to use the thing with mechanical sympathy, aligning my work with the grain of the implementation details. I want to understand error messages when they happen. I want to know how to diagnose something when it breaks, especially when it's something as important as my data.

I like how ZFS is put together. I've been running it for about 13 years. I started with Nexenta, a Solaris fork with Debian userland. I've ported my pool twice, had a bunch of HDD failures, and haven't lost a single byte.

I agree with you on most of the encryption stuff. That is very recent and not fully integrated and the user experience isn't fully baked. I don't agree on unifying zpool and zfs; for a good long time, I served zvols from my zpool, and dividing up storage management and its redundancy configuration from file system management makes sense to me. Similarly, recursive datasets make sense; you want inheritance or something very like it when managing more than a handful of filesystems. I don't agree on pool names (why anyone would want ordinal pool naming and just replicate the problem you just stated re sda, sdb etc. is a bit mysterious), and I don't agree on snapshots (to me this is like preferring commit IDs in git to branch and tag names - manually created snapshots outside periodic pruning should be named).

ZoL on Ubuntu does periodic scrubs by default now. Sometimes I have to stop them because they noticeably impact I/O too much. Periodic snapshots is one of the first cronjobs I created on Nexenta, and while there's plenty of tooling, it also needs configuration - if you are not aware of it, it's an easy way to retain references to huge volumes of data, depending on use case. Not all of my ZFS filesystems are periodically snapshotted the same way.

I see the utility in recursive datasets and I wouldn't want them to go away, but if I were creating a zfs-for-dummies I wouldn't include the functionality. You'd have to drop down to the raw zpool/zfs commands to get that.

Likewise, I appreciate being able to name snapshots, but it's annoying to have to manually name the snapshot I create in order to zfs send. The solution there is probably to not make me take a manual snapshot in the first place. `zfs send` should automatically make the snapshot for me. But in general, I don't see why zfs can't default to a generic name and let me override it with a `--name` flag.

Giving it more thought, I think I would keep pool naming. What I don't like is the possibility of having pool name collisions which isn't something you have to think about with, say, ext4 filesystems. But the upshot, as you point out, is with zfs you aren't stuck using sda, sdb, etc.

What's the lifecycle of an automatically-created snapshot? i.e. is the snapshot garbage? How does it get collected? Things like autosnapshot implement policy to take care of itself but... zfs send one-offs?

zfs send is a strange beast. It's more like differential tar than rsync (i.e. a stream intended for linear backup). zfs is cool because it unifies backup/restore. Have you tried restoring differential tar from unlabeled tapes?

I’m on the other end of the spectrum. I like knowing the flags and settings I use to create the pools.

For snapshots and replication take a look at sanoid (https://github.com/jimsalterjrs/sanoid).

— when destroying a dataset, please ask for confirmation before permanently deleting it

— please provide support for multiple key slots as in LUKS

— please build in the functionality of sanoid and syncoid, so that snapshots and replication don’t need a third party tool

— please build a usable deduplication, so that we don’t have to use external tools such as Restic or Borg

Do you use Restic or Borg with ZFS? How do you have that set up? Do you use them in lieu of zfs send/recv?

In liu of ZFS replication (send and receive). I still use ZFS as a file system.

Also, I have a 1.5TB directory. There is a lot of redundant backup data in it. I archived it with Restic to 400 GB. As a ZFS dataset, it would have taken ~4X the size.

Honestly, backups up to 100 TB are better be done with tools such as Restic than file system stream backups: less hardware requirements, lots of support for repository management, integration with clouds, portable repositories, better and more trusted encryption, etc. Tools based on Go are static binaries with no dependencies. You can recover your data in the future on any X86 platform.

Fully agree on using tools such as Restic! The `--exclude-caches` is really helpful in keeping backups small, it makes Restic skip directories with a CACHEDIR.TAG file and that includes Rust compile target directories. Combined with a small exclude list for browser caches and other temporary storage this makes backup deltas way smaller than in the average ZFS setup. (And no, creating a new ZFS filesystem for every cache directory and excluding each of them from snapshots is not really a solution)

I searched my linux system for CACHEDIR.TAG and found only a handful of them. Also looking at the standard’s website, it seems it’s not adopted.

I make remote snapshot backups with Borg using this: https://github.com/Freaky/zfsnapr

zfsnapr mounts recursive snapshots on a target directory so you can just point whatever backup tool you like at a normal directory tree.

I still use send/recv for local backups - I think it's good to have a mix of strategies.

I’m not sure what restic or borg are or do for you, but there is an upcoming feature called “block cloning” that is a sort of on-demand version deduplication that offers new advantages for certain setups.

https://www.bsdcan.org/events/bsdcan_2023/sessions/session/1...

Borg/Restic are deduplicating backup tools. They actually use the exact same approach as ZFS deduplication, but because e.g. Borg chunks are around 2M instead of 128K (ZFS recordsize default) it uses less memory for the same data compared to ZFS. All of these systems end up using somewhere around 300 bytes of memory per chunk stored. [1] This is how you arrive at the "1 GB of memory per 1 TB of storage" rule of thumb when using deduplication.

Block cloning is different because it's offline. It does not require deduplication tables, therefore does not require those 300 bytes per chunk I mentioned above, neither on-disk nor in-core. Note that the BRT only has to track blocks which are actually referenced at least twice, while the DDT has to track all blocks. This, plus the BRT not having to store the block checksum, is why it has so much less overhead. The BRT should come out to less than 20 bytes per tracked block on average. (Also, the BRT is only used for freeing blocks and when handling ficlonerange, while the DDT has to be consulted for every prospective block write).

The downside is of course that it's offline. So the finding of duplicate blocks, which is what all the DDT overhead supports, has to be done by an external tool, unless you're explicitly creating duplicates (cp --reflink=always), which is of course a very useful thing to have -- especially because block cloning works across datasets: with block cloning you can actually copy data out of snapshots back into a writable dataset without having to physically copy anything. Also, again, as it's offline, you can deduplicate existing data in-place, while traditional ZFS dedup would require turning deduplication on and then re-writing all data you want deduplicated.

So OpenZFS 2.2 is definitely going to be very exciting.

[1] Some use more memory in-core than on-disk, e.g. Restic tends to use about 2-3x the memory relative to Borg, Rustic is somewhere in-between. Probably GC tax.

> - Make encryption just on or off instead of offering five or six options

You can set "encryption=on", and it will select the default strongest option, currently AES-256-GCM

> - Generate the encryption key for me, set up the systemd service to decrypt the pool at start up, and prompt me to back up the key somewhere

Technically it does generate encryption keys internally, which is why the ones you provide can be rotated out. If you use a keyfile then automount with key load is easy (zfs mount -al), there is already an auto mount systemd service created automatically for Debian, however they did not add the -l flag for auto loading keys because they got stuck in a debate about supporting passphrase prompts at boot. For now you can simply edit it to add the -l flag and it work fine for datasets with keyfiles.

> - Don't make me type disk IDs when creating pools. Store metadata on the disk so ZFS doesn't get confused if I set up a pool with `/dev/sda` and `/dev/sdb` references and then shuffle around the drives

This is no longer the case for ZoL. I know because there is an issue with Linode for storage device identifier assignments where they consistently get jumbled up with Debian on every boot. ZFS finds the devices all the same, even if it has a different identifier every boot. I believe this is because it stores it's own UUID info on the devices. So you can create pools by referring to devices however you like, because they are only a temporary reference, i.e use /dev/sda etc (and I have, and it's fine). I think there is a lot of outdated advice about this floating around still.

> - Automatically set up weekly scrubs

This might be ZoL specific, but, the Debian package does exactly this, sets up systemd weekly scrub.

> - No recursive datasets

Why? this is too useful... inherited encryption roots, datasets with different properties so you can have databases and other filesystems all under the same root dataset, which can then be recursive replicated in one command. If you have no need for recursive datasets just don't use them, but they have many valid purposes.

this is honestly hard because many of the decisions that matter are not things you type into zfs at all (except incidentally).

how many disks per vdev? how much memory? etc

a lot of the things you've outlined are not universal at all, just situational

Yes, there is a lot of essential complexity that is unavoidable, but there are a lot of people like me who just want a better desktop file system, and we don't need to know about SLOGs and L2ARCs and the half dozen compression algorithms, etc. It's situational, but it's a common enough situation that a targeted solution would be valuable.

I'm one of those who wants a better desktop file system but have stayed away from ZFS (at least for the time being) due to stories about complexity.

Would you say that the defaults are sane enough for that kind of person (no real configuration needed)?

No, not really. There's a lot of unavoidable complexity like needing to understand what ZFS pools, vdevs, and datasets are and how they relate to each other. And then if you want to encrypt your data that adds another bit of functionality you need to configure. And then there are just a lot of things that aren't that important for most people, but you won't know if it's important for you until you understand what they are.

I would say the learning curve is similar but perhaps a bit steeper than configuring vim for web development for the first time or configuring nginx and let's encrypt on a webserver for the first time.

It didn't help that I started by trying to setup root on encrypted zfs. I would recommend first using zfs unencrypted, then adding encryption once you're comfortable with that, and finally trying /home on zfs or even root on zfs.

The defaults are absolutely sane. I've been using FreeBSD with root on ZFS on all sorts of workstations and laptops for many years now. It's always run just fine, even on cheap laptops with 2 GB of RAM.

I think the key thing to note there is that you are on FreeBSD. The Linux integration isn't nearly as mature.

I switched away from ZFS on root after using it for about a year. There were no actual problems, but I could never get over the fact that it's so complicated underneath I have to relearn everything every time I do any sort of advanced maintenance.

For example, I had to move between SSDs which is an absolutely trivial operation with any other filesystem if you know your Linux well. It took me maybe three hours of work on ZFS because it brings its own environment and does everything its own way, so I had to remember and re-discover a lot of stuff. The system booted on maybe 15th try.

If you are fine with this, or you're not going to use it on root, or you are a FreeBSD user, it's an excellent choice for pretty much any task.

I have zfs root on ubuntu; moving to another ssd was trivial: add the second drive, recreate the partition scheme (esp, bpool, rpool), add them as mirrors to existing pools, and while waiting while it mirrors up, reinstall grub on the new esp. After mirroring is done, check fstab for UUIDs, reboot, check, whether everything is ok, remove the old drive from the mirror. Done.

Though I consider zfs to be nice, I'm willing to use it only with distributions, where it comes with the distribution, built for the distro kernel (i.e. ubuntu or proxmox). In the past, I've wasted too much time with dkms, failing to build the kernel modules, or kABI modules failing to load, or other problems that left me without root filesystem at reboot. That's not an experience I'd like to repeat. Also, btrfs is nice too ;).

Is the integration of root zfs on linux complicated? I saw some info-graphic and it looked like there were a lot of pieces to stitch it together. Is it fragile?

Regardless, I'm surprised your one-year with ZFS didn't convinced you that it's worthwhile to invest in its mastery. The filesystem will pay dividends for your entire compute life-time and not only save your data but hours of maintenance over that time.

Major downgrade moving away from it in my view.

On a side note, FreeBSD is great and worth investing in as well. I still have more to learn but the journey has been wonderful and I will not be using Linux in the next iteration of my home / lab server and hobby projects.

Outside of it being a good idea to manually set `ashift=12` on each vdev creation (because disks lie and zfs’s whitelist isn’t omniscient. I’ve seen too many people burned by this) and `atime=off` for datasets (because burning IO updating the metadata because you’ve accessed something is just fucking stupid), the defaults are sane and you can basically refuse to care about them after that.

Every system I’ve used has `compression=on` set as default, which currently means lz4. People set it manually out of paranoia from earlier days I think.

For linux systems you can set `xattr=sa` and `acltype=posixacl` if you like, which offers a minor optimization that you’ll never notice.

I suppose if you don’t like how much memory zfs uses for ARC, you can reduce it. For desktop use 2-4gb is plenty. For actual active heavier storage use like working with big files or via a slow HDD filled NAS, 8GB+ is a better amount.

Dataset recordsize can be set as well, but that’s really something for nerds like me that have huge static archives (set to 1-4MiB) or virtual machines (match with qcow2’s 64KiB cluster size). The default recordsize works well enough for everything that unless you have a particular concern, you don’t need to care.

I should note, beware of rolling release linux distros and ZFS. The linux kernel breaks compatibility nonstop, and sometimes it can take a while for zfs to catch up. This means your distro can update to a new kernel version, and suddenly you can’t load your filesystem. ZFSbootmenu is probably the best way to navigate that, it makes rolling back easy.

You also want to setup automatic snapshots, snapshot pruning, and sending of snapshots to a backup machine. Highly recommend https://github.com/jimsalterjrs/sanoid

If you really find yourself wanting to gracefully deal with rollbacks and differences in a project, HotTubTimeMachine (HTTM) is nice to be aware of: https://github.com/kimono-koans/httm

If you install on ZFS from the installer with Ubuntu, FreeBSD, Illumos, etc. there's no reason to care about the complexities under the hood if you don't care about them with any other file system.

It's like saying you should know how virtual memory and pre-emptive multitasking work if you want to upgrade from Classic Mac OS to OS X.

`compression=on` exists.

You don't need to know about SLOGs and L2ARCs. They're not super useful generally but people geek out a out them.

I know those were just examples and I don't disagree with the general point.

Why would you want to know about SLOGs or L2ARCs if you're using it on a desktop? Even if you are using it for a NAS, you almost certainly don't need to know about those.

I'm also firmly on the "convention over configuration" mindset, sensible defaults should be available and anybody else can still tinker if needed. I also admit that setting up zfs wasn't easy for me (and I'm sure I haven't done it 100% properly)

I get that it's meant but be wrapper for common use cases, but I use ZFS on root and had to craft a custom initfs. The other nice-ities sound great (some BTRFS inspiration?), but some of these are at distro-devel level.

I looked into doing root on ZFS, but I ended up settling for /home on ZFS. Maybe I'll revisit it next time I build a new system when I'm more comfortable with ZFS.

> The learning curve is steeper than I expected

In fairness, learning about zfs is like learning about mdadm, lvm and a filesystem all at once… so it’s kinda justifiable in my opinion

I'd write a wrapper to do much of that to automate whatever my particular use-case is.

One pattern I've found useful when writing wrapper shell scripts: Output the actual command(s) that actually get run, to stderr in yellow, before running them. This also serves as a sanity check.

> - Generate the encryption key for me, set up the systemd service to decrypt the pool at start up, and prompt me to back up the key somewhere

This should have an option to integrate use of a TPM for super-encrypting the ZFS encryption key(s).

> - collapse `zpool` and `zfs` into a single command

Nooo, that should not be done. They are very different tools, for very different things.

I expect that that’s what Apple would have done if they had adopted ZFS, sensible defaults for the common user.

This is a very funny list.

"Sane defaults", are you going to be arbiter of sanity? With the #3 recommendation, "set up systemd for me", I'd rather not have you at that position.

Most of the bullets you wrote induce a "...why?" thought in somebody that has ZFS experience. Why would you unify zpool and zfs? Why would you want automatic weekly scrubs on as default? Do you realize what ZFS scrubbing is and when is the time to perform it?

I'm a bit agitated by your writing I must confess. You want ZFS to exactly reflect your basic use case so you don't have to move your little finger (automatic naming, automagical configuration). It's not meant to be a hands-off filesystem, you are expected to understand encryption in ZFS in order to use it.

But the most annoying thing is that you did see a steeper learning curve, and want to avoid it. Why don't you write your own ZFS provisioning tool? Why are you still using /dev/sda and not disk-by-UUID or something more 2023? Etc.

Like I said, I just want a wrapper to make this stuff easier for me. It's just like not everyone wants all that comes with running Arch. Some people like having Ubuntu handle the nitty gritty of a Linux OS. What's wrong with that?

> It's not meant to be a hands-off filesystem,

??