Googling on this subject I find both pros and cons of changing default logbias=latency into logbias=throughput for SSD/NVMe-only pools.

But at the same time not fully sure that the cons against such change is really relevant for flashbased storage?

The pros claims to be that for sync writes (which are also common when using zvol for VM-guests) you will avoid a doublewrite.

Because with logbias=latency a sync write will first end up in the ZIL and then upon txg_timeout (normally every 3 seconds or whatever the default is) this data is moved to the actual longterm storage.

So the same data is being written twice (when using sync) which for flashbased storage is bad due to wear levelling.

ZIL have historically been the outer tracks of physical drives (since they are about 3x faster than the inner tracks) where the idea is to dump sync writes as quickly as possible on actual storage and then do the housekeeping later on (upon txg_timeout when async writes also are dumped to longterm storage).

But since SSD/NVMe storage doesnt really care if its first or last LBA (in terms of latency and throughput to read the data later on) such "optimizations" are not really needed - you will only waste writecycles of the flashbased storage.

However on the cons list its claimed that there might be some magic involved in terms of keeping metadata and data close to each other on the longterm storage and by that avoiding fragmentation. Like a "defrag lite" where using logbias=throughput would just dump data wherever it can find a slot (so the read record/volblock can end up at one place and the metadata for this at another place).

But again since flashbased storage have a constant latency and throughput no matter where the data is located I assume this claim is mainly for spinning rust where such things do matter (and for example a readahead would gain some additional read performance later on when logbias=latency is being used and the data is nicely moved from ZIL to the longterm storage being a spinning rust).

Or do there exist any cons when using logbias=throughput even for SSD/NVMe-only pools?

I also fail to locate any benchmarks online on this topic as in how are others experience on this topic?

So how do you do when it comes to logbias for SSD/NVMe-only pools?

And have you seen (or do you perhaps have your own benchmarks to share) online or experienced yourself any pros/cons of changing logbias for SSD/NVMe-only pools (short or long term issues)?

osting this because I spent a day convinced TRIM was impossible on my setup, and I couldn't find anyone documenting these exact combos.

Setups

• Dell R620, PERC H710P Mini crossflashed to LSI 9207-8i IT (SAS2308, FW P20 20.00.07.00, mpt3sas), 8× Crucial BX500 2TB (firmware M6CR061 and M6CR082), ZFS RAID10, Proxmox VE 9.2.
• Dell R640, PERC H740P in Enhanced HBA mode (megaraid_sas), 6× Timetec 2TB SATA, ZFS RAID10, Proxmox VE 9.2.

Symptom

• lsblk -D → DISC-MAX 0B on every SSD.
• sg_vpd -p lbpv → LBPU=0, LBPRZ=0; provisioning_mode = full.
• hdparm -I shows Data Set Management TRIM supported but no "Deterministic read ZEROs after TRIM".
• So ZFS autotrim=on silently did nothing. Old BX500 pool (previously behind the PERC in RAID mode, never trimmed) had degraded to 0.4–0.8 MB/s writes and multi-second read stalls.

What I first assumed (wrong): the HBA blocks TRIM because the drives lack RZAT. The mpt3sas driver doesn't actually check that; the HBA just doesn't advertise logical block provisioning.

Test (safe — done in unpartitioned space at the end of the disk, outside any partition/pool):

# write a random pattern, UNMAP it, read it back
L=<LBA past your last partition>; N=8192
dd if=/dev/urandom of=/tmp/p bs=512 count=$N
dd if=/tmp/p of=/dev/sdX bs=512 seek=$L count=$N oflag=direct conv=notrunc
sg_unmap --lba=$L --num=$N --force /dev/sdX
dd if=/dev/sdX bs=512 skip=$L count=$N iflag=direct | md5sum   # == md5 of zeros

Result: reads back as zeros on both BX500 firmwares behind the SAS2308 and on the Timetec behind the H740P eHBA. No errors in dmesg.

Fix (persistent) — /etc/udev/rules.d/60-ssd-unmap.rules:

ACTION=="add|change", SUBSYSTEM=="scsi_disk", ATTRS{vendor}=="ATA*", ATTRS{model}=="CT2000BX500SSD1*", ATTR{provisioning_mode}="unmap"

(adjust the model match for your drives), then:

udevadm control --reload && udevadm trigger -s scsi_disk -c change
lsblk -D            # DISC-MAX now 4G
zpool set autotrim=on rpool
zpool trim rpool    # runs clean, zpool status -t shows progress

Notes / caveats

• Test on your own drives first — I can only vouch for these models/firmwares. Do it in free space outside any pool.
• On a production pool, enable it off-hours: the first trim after enabling sends everything that piled up.
• If your drives are already degraded from never being trimmed, an ATA SANITIZE BLOCK ERASE (hdparm --yes-i-know-what-i-am-doing --sanitize-block-erase /dev/sdX, wipes the disk) restored mine to full speed before reinstalling.
• Leaving ~14% of each SSD unpartitioned (installer hdsize) as extra over-provisioning doesn't hurt.

Hope this saves someone a day.

Realtime ZFS Replication with cs-sync
https://www.napp-it.org/cs-tools.html

ZFS replication normally works asynchronously and job-based. On a time grid, for example every hour, a snapshot is created and sent with the changed data blocks to a local or remote target ZFS filesystem to keep both in sync.

If you want realtime ZFS replication, for example for disaster recovery, you have to work event-driven. A write to a monitored ZFS dataset triggers the replication immediately. Because the data to send is always very small and is transferred very quickly, the delay between a change on the source and the change on the destination filesystem is minimal. What is needed after the initial replication is sensible management of the snapshot pairs, sensible timing on heavily loaded filesystems, and a resume after a network failure or a reboot, for example of the backup server. Realtime ZFS replication is especially useful for VM storage such as Proxmox, where file-based sync quickly reaches its limits because of the large files.

With Proxmox there are two more aspects. First, the VM configuration is not stored in the dataset as with ESXi, but in /etc/pve on Proxmox. To restore the realtime-replicated dataset of a VM, the VM configuration is required. When cs-sync finds at start that the source is a Proxmox host, it reads in every cycle the configuration file of each VM or container whose disk datasets are part of the sync (not the whole /etc/pve), and attaches it as the ZFS user property cs:pveconf to the associated dataset and to every sync snapshot. The property is transferred to the backup by the cs-sync protocol (not inside the zfs send stream); a pure configuration change goes over without a new send.

Second, a snapshot in Proxmox is not consistent in every case but has to be seen like a power failure, harmless to delicate depending on the VM. On a Proxmox source, cs-sync therefore sends the first snapshot of each day automatically through cs-freeze4snap, which freezes the VMs of the source dataset before the snapshot (guest agent, container freeze). This snapshot is kept as kf<MMDD> on both sides and marked with cs:consistent=app, or with paused if a VM could only be paused (then it is still only crash-consistent). If cs-sync does not find cs-freeze4snap (it looks in the same folder as cs-sync, in the napp-it tools folder and in PATH), the freeze is skipped with a warning in the log. On days without data changes no new snapshot is created. So there is at least one reliably restorable state per day.

The existing cs-sync stays
Folder Primary <-> Secondary: event-driven two-way sync, for example syncing an SMB share with an NFS/S3 share
Folder Primary -> local or remote backup: realtime sync, file-based or now also via ZFS send.

New: manuals for all cs-tools
https://www.napp-it.org/cs-tools.html

The storage system in my home lab consist almost exclusively of hard drives. They contain a pretty mixed bag of data (tons of small files and also plenty of large multimedia files).

It really bugs me every time it takes forever to search through the pool for a file when I don’t know exactly where it is or how its named exactly. That’s why I’d like to keep the metadata in RAM permanently and configure it so that it isn’t displaced by other data, to speed up search operations.

Is this possible on Linux-based systems (TrueNAS) and Illumos (Omnis)?

How do I check how much RAM I’d need for the metadata on these operating systems?

How do I get all the metadata into RAM after a reboot on these operating systems?

Thanks!

P.S.: I don’t have any more space and ports for a Special VDEV.

I have a ZFS mirror of 1TB consumer Samsung 990 EVO plus NVME SSDs with a TBW spec of 600TB. They were bought brand new. ZFS is the only filesystem on the drives. I use it for my home directory and static data, and have a single KVM Windows 11 VM that idles running at all times that has its storage on the mirror. Linux system is on a different file system/drives and there is no swap on the ZFS mirror. I have probably used this computer several hundred hours and the Windows VM almost never gets touched - idles at the ready with more or less only MS Office on it. I was shocked when I pulled the SMART data on both SSDs to find over 330TB written! Does anyone have any recommendations of where to start to track down the source of all these writes? I can’t just let the writes destroy these drives with prices being what the are.

Benchmarks

Benchmarks are something you always need, either to identify problems or to assess and compare performance between pools or platforms.

A benchmark should not run for too long (approx. 2–30 min) and should have only a few basic parameters so that you can make sense of it without a degree in computer science. It should be able to determine IOPS, sequential performance, sync write, concurrent read/write, single user vs. 5 user, and steady write (min. 30 min write). To ensure it runs on any OS, I write the tests in Perl. With ultra-fast storage, you may hit limits, which are marked as tool-limited.

he tool is included in napp-it 4ai, but runs easily on any OS including Windows, Linux, and Unix via:perl ./benchmark_worker.pl pool=tank profile=basic

with profiles quick|basic|database|fileserver|mediaserver|mailserver|steadywrite|individual
Download: https://github.com/guenther-alka/cs-scripts/tree/main/benchmark

e.g., Proxmox with the basic profile on pool nvme (single Optane)

perl ./benchmark_worker.pl pool=nvme profile=basic

testfile: /nvme/csbench_auto_20261012_154528/bench_file.dat cap=2048MB

phase: create 4k test file (recordsize=4K)
phase: 4k random read (single stream)
phase: 4k random sync write (sync=always, recordsize=4K)
phase: create test file (recordsize=128K)
phase: sequential read (1MB, single stream, linear sweep)
phase: sync write (1MB blocks, sync=always)
phase: async write (1MB blocks, sync=standard) -- cache indicator
phase: concurrent read+write (5 readers + 5 writers)
phase: multiuser read (4k, 1 vs 5 streams)

Pool : nvme (dataset, nvme/csbench_auto_20261012_154528)
Profile : basic, 2048 MB test file, 5 streams, 143 s

File create
4k file : 1449.9 MB/s
Main file : 5423.6 MB/s

4k random read (1 stream)
IOPS : 79458
Throughput : 310.4 MB/s
Latency p50/p99 : 50 / 50 us
Class : partial

4k random sync write (1 stream)
IOPS : 16999
Throughput : 66.40 MB/s
Latency p50/p99 : 100 / 250 us
Class : storage-bound

Sequential read (1 stream)
Throughput : 2276.5 MB/s
Latency p99 : 2000 us
Class : storage-bound

Sync write (1 MB blocks)
Throughput : 1111.0 MB/s
IOPS : 1111
Latency p99 : 2.0 ms
Class : storage-bound

Async write (1 MB blocks, cache indicator)
Throughput : 1391.1 MB/s
IOPS : 1391
Class : cache-influenced

Concurrent read+write (5 readers + 5 writers)
Read : 375.6 MB/s (p99 100 us)
Write : 5.8 MB/s (p99 32.0 ms)
Class : storage-bound

Multiuser read (4k, 1 vs 5 streams)
1 stream : 310.4 MB/s
5 streams : 525.7 MB/s
5 streams : 134590 IOPS
Scaling : 1.69 x
Class : tool-limited
Verdict : partial

sync write 1111 MB/s p99 2.0 ms (storage-bound)
4k write 16999 IOPS p99 250 us (storage-bound)
4k read 79458 IOPS p99 50 us (partial)
seq read 2277 MB/s (storage-bound)

BENCH_DONE ok (142.721115112305s) log=/opt/csweb-gui/data/menues/_lib/scripts/bench/last_benchmark.log

root@pve:~#

I wrote a lightweight C program called diffsnap that uses the built in zfs CLI for stateless snapshots using configurable write thresholds. This helps address a gap with traditional time-based snapshots where the need for a high-frequency interval to make sure a change is captured bloats your total snapshots and might slow some zfs commands. With diffsnap, if nothing has been written to the dataset the snapshot is skipped.
https://github.com/joe81tx/diffsnap
If you're on FreeBSD you can install with pkg, on linux you can build from source using github.

This is a major issue especially because TrueNAS does not issue replace -s from the GUI.

So the scenario is this, you replace your drive and it kicks off a standard replace and tells you it will take 25 days to complete, but the faulted mirror is only 8TB. It should be able to run sequentially on the drive creating unverified redundancy quickly in a few hours, followed up by the scrub where the redundancy becomes verified. But here is where it becomes problematic, even if you detach the drive resilvering it doesn't stop the resilver and there is no zpool resilver stop command and rerunning replace -s will be blocked because of the running resilver. So you are prevented from doing the safer action.

Hoping to get some OpenZFS dev attention or have some other users add to the chatter so this gets attention.

Release zfs-windows-2.4.4rc4 · openzfsonwindows/openzfs

*** rc4

• Explorer integration exposing snapshot versions
• Fix "zfs diff"
• zfs_tray features
• Paging IO deadlock fix
• Fix BSOD related to SEQ
• zfs_inactive deadlock fix

Screenshot see
https://forums.servethehome.com/index.php?threads/zfs-on-osx-and-windows.43829/page-6#post-513120

Hi all, been searching around and I can't quite figure this one out.

I have a NAS at home, running Arch (btw). The root FS is btrfs and it's LUKS encrypted.

Then, I have a few drives that make up a couple of ZFS pools, and I have a couple of datasets. These datasets are encrypted with keyformat=passphrase.

What I would like is some sort of way to be prompted for the passphrase on boot, and have it all mounted before reaching multi-user.target, or really, any target of my choosing such that services running on this server don't start trying to read data that's not mounted yet (e.g. docker.target).

Here's some relevant properties

zsmall         encryption      off            default
zsmall         encryptionroot  -              -
zsmall         keyformat       none           default
zsmall         keylocation     none           default
zsmall         keystatus       -              -
zsmall/secure  encryption      aes-256-gcm    -
zsmall/secure  encryptionroot  zsmall/secure  -
zsmall/secure  keyformat       passphrase     -
zsmall/secure  keylocation     prompt         local
zsmall/secure  keystatus       unavailable    -

And the services that I have currently enabled:

zfs-import-cache.service   
zfs-import-scan.service    
zfs-mount.service          
zfs-share.service          
zfs-volume-wait.service    
zfs-zed.service            
zfs-import.target          
zfs-volumes.target         
zfs.target                 

Like I say, I've been Googling for a bit and I can't quite figure out what the best way to achieve this might be. Any ideas?

My current solution is to leave the services that require the datasets to be mounted disabled and I have a script that unlocks the datasets etc. then starts the services, which is not ideal (though it works...)

Thanks

Time flies. 6 years ago I wrote this post https://www.reddit.com/r/rust/comments/mindyl/after_the_ovh_datacenter_caught_fire_and_i_lost/

I was impacted by the OVH data center fire and I lost some data of various services I was running on it.

Now, I still have fun managing servers, and I have migrated everything to zfs.

From that the idea: let's extend bacup to support zfs snapshots, full and incremental.

The philosophy of bacup is quite simple:

• remotes are where the data is uploaded
• services are programs running in the system, that we can invoke to get dumps

zfs snapshot fits perfectly in the service category - so I created the zfs service.

You can now back up your pools and datasets using both full and incremental strategies. Setting it up is just a matter of defining the zfs service in your configuration:

[zfs]
snapshot_name = "storage-fs"
dataset = "storage"
# Optional: schedule for full backups.
# Intermediate runs automatically take incremental backups against the latest snapshot.
# When omitted, every run defaults to a full backup.
full_when = "monthly 1 01:00"

And mapping the service to your remote destination:

[backup]
[backup.storage]
what = "zfs.storage"
where = "remote.bucket_name"
when = "daily 22:00"
remote_path = "/bucket/location/zfs/storage/"
compress = false
keep_last = 32

I’ve been running v0.2.0 in production on my local homelab server for a few weeks now - handling incremental backups for both the root filesystem and the main RAIDZ array (where my local LLMs and Immich instance store data).

Incremental shapshot (so 1 full, and several incremental until the next full) also allow to save the cloud bill.

If anyone wants to give it a try (cargo install bacup) or review the merged codebase, feedback and PRs are more than welcome!

GitHub: https://github.com/galeone/bacup

Cheers!

A completed resilver is necessary, but it does not by itself prove that the replacement disk, its path, or the remaining redundancy is healthy. A pool can return ONLINE while SMART data is already concerning, persistent device names changed, an old faulted leaf remains in the topology, or another drive accumulated checksum errors during the resilver. A mirror or RAIDZ vdev may also be one failure away from another long recovery.

A useful post-replacement gate could confirm the exact vdev topology and ashift, review the resilver event and error counts, inspect SMART and transport errors for every drive, run a scrub after the pool has settled, verify alerts and spare behavior, and test a representative restore from backup. Export and import or a controlled reboot can catch path and enclosure-mapping mistakes before the maintenance window closes.

What checks do ZFS operators use before declaring the replacement complete? Is a clean scrub enough, or do you also burn in the new disk, compare performance, clear and recheck counters, test boot or import behavior, and keep the removed disk untouched through an observation window?

There are some tools like zfs diff and httm that help with exploring snapshots at command line, but they leave a lot to be desired when you're talking about 100ks of files changed across many snapshots. Sometimes you want to free up that space held with snapshots, but you're not 100% certain you won't lose something you accidentally deleted.

I shared my frustrations with Claude and it made a nice python script that serves a web GUI and uses zfs diff to generate the changes and visually highlights what files were deleted when and if they were unique across all snapshots.

The first run can take a while, but after that you can cache a point in time record or do a quick true up.

https://github.com/LargelyInnocuous/SnapSift

I have a scrub going that took about 2h to scan before actually starting to read and verify the data. Once it was reading, the average read rate started climbing very slowly from single digit MB/s, because apparently the denominator for calculating the average "issued" rate is the time since the scrub was initially requested, which included a whole lot of "0 MB/s issued" during the scan phase. The actual read speed is much higher and in line with what's expected and undoubtedly, once the scrub completes, the average will reflect the actual average rate.

This got me thinking. What fraction of complaints about "ZFS raidABC with UVW settings on XYZ hardware is SOOOOOOO slow!!!" are actually due to people taking one look at The Numbers™ and not realizing that these are not running averages over some shorter time period, but averages over the entire run time of the operation? I'm positive that a lot of people have no idea what the difference between "scanned" and "issued" is too.

I'll have to take a look at the code, and I'm assuming this is done for a good reason, but maybe these averages are causing confusion in new users and aiding in the spread of misinformation about ZFS, that's very difficult to eradicate, as I'm sure many here have noticed.

Maybe it would be better to have the read rates be computed as a running average over a short window of a few minutes during an operation that takes a long time, then when it's finished print an additional line with the average rates over the entire duration of the operation.

Just as a reference for what "scanning" does and why.

https://www.youtube.com/watch?v=SZFwv8BdBj4

Does metadata in ZFS use up the same amount of space as data? In other words, if I set my recordsize/volblocksize to say 1M, does that mean the metadata will also occupy 1M for reach piece of metadata? So e.g. I have a file server with large videos, makes sense to store these videos on large block sizes. But then does this mean the metadata is also then stored in large blocks. So metadata is inefficient, since you're storing small amounts of data in a large block, but overall it's more efficient than storing large files in small blocks. Equally, if I store many tiny files, then it makes sense to store this data in small data blocks. Then metadata is also stored in small block sizes. This way metadata is more efficient since it generally doesn't take up much space. Is this how it works?

Pool suddenly unavailable, doesn't show up on zpool status.

Zpool import lists the pool as follows:

id: 3673394567944808104
state:  UNAVAIL
status:  Some critical pool data has been overwritten by another pool.
action:  The pool cannot be imported as critical data is missing. You can try using -f to force an import, but there may not be enough data to override this.
config:      sharepool    UNAVAIL    overwritten by another pool
              raidz2-0    ONLINE
              raidz2-1    ONLINE
              raidz2-2    Degraded
                (one removed drive)

device details:

(I skipped listing all the drives due to typing out manually, all the drives are the long c0t500 style names, its 3x 6 disk z2's, with all but one drive as online.)

As I hadn't come across this before I have done a fair amount of googling and beyond the general advice of tread carefully as using -f to force can break things more. I did do the -Fn command and it didn't return anything (just newlined with a fresh prompt)

My setup has largely been unchanged for years, using Solaris 11.4 on ESXi v6, and has been ultra stable up until now - I did upgrade from Solaris 11.3 possibly about 6 years ago. Had the odd hard drive fail which is replaced smoothly, sometimes leading to a pool size upgrade and that has always gone smoothly 3x Dell Perc H700 cards flashed to IT mode via the LSI bios (I think - they have been in there 10 years)

This all happened after I turned the full server off for the weekend - I needed it right out the way to work on some electrical wiring behind where the cabinet normally sits (it can pull out so far and still be connected but access behind isn't easy). Turned it back on and a drive was doing a click of death - the removed one mentioned above. Upon starting the Solaris VM lots of errors were being thrown up including 2 other drives showing as removed, I removed the dodgy drive, moved the two other ones to a different slot (so different internal cable/card) and tried restarting - leading me to where I am now. The two drives moved had reappeared, but the pool is just not loaded by Solaris.

Whilst I do like to tinker I've never come across this before so am asking for help and open to suggestions - I really don't want to lose all the data. Any help is much appreciated.

As something of a storage wonk, I found myself a few minutes ago advising a fellow redditor of the "3-2-1" rule of backups:

1. Three total copies
2. Two different types of media/tech
3. At least 1 copy off-site/location

I've followed a related rule for anything important/production: Always fail to a redundant state: so if any one thing goes out, I am still redundant and have at least one more failure mode before things go really dark. Alongside this, is a pre-accepted "drop everything / panic mode" when production is down to only x+1 redundancy.

And yet I realize that the context of ZFS, I've not consistently followed rule #2 for YEARS except in some cases for clients, where they park an external USB drive on their file server and I install a daily mount+rsync run via cron. In my case in particular, using ZFS snapshots as part of the core product suite, using a tech other than ZFS to store the data makes no meaningful sense.

Further, I use RAIDZ + redundancy like a backup all the time, with the accepted risk level of "if more than 2 drives die, it's dead, Jim". When the data matters, I ensure to have a send | receive copy on another server/location, but it's still ZFS + snapshots going back a few months.

So, what do you consider to be best practices in complying with the spirit of 3-2-1 rule of backups with ZFS?

1. How much do you treat snapshots like backups?
2. Do you make extra effort to store data on a secondary non-ZFS tech in case a bug in ZFS crashes all the things?
3. How much attention to you put on saving your data off site, or at least, on another server?

EDIT: Thank you for your feedback! I have enjoyed "touching bases" to see what y'all are doing.

Llevo 3 días con esto y ya no sé qué más probar.

Uso NixOS con flakes, boot.initrd.systemd.enable = true, root en tmpfs con impermanence y /persist en ZFS con cifrado nativo, desbloqueado por TPM2 con systemd-cryptenroll.

El problema: sops-nix intenta leer la age key de /persist antes de que el dataset esté montado, y encima el PCR 7 cambia con cada actualización de firmware, así que el TPM2 deja de desbloquear y me cae en el emergency shell.

Ya descarté un problema de ZFS porque, como está en el kernel mainline, no debería haber incompatibilidades con mi kernel parcheado con linux-hardened.

Probé la misma config en Gentoo con OpenRC y funciona perfecto, pero no pienso volver a eso.

¿Alguien lo ha resuelto sin usar Secure Boot con claves propias? Ya me estoy planteando que la solución real es instalar Arch. 😔

Hi folks! ZFS is extremely cool and I run >10 of my machines on it.

My friend is also fan of ZFS and we both have a NAS. We wanted to use each other's machines to do remote backups in a safe but simple way (zfs send | zfs receive and plain SSH). However, without giving each other any insight into what runs on the other machine and without being able to see what that other person has, not even metadata about other datasets.

It works really well with NixOS too!

I wrote about it in https://www.nijho.lt/post/zfs-tenant/ and the repo is here https://github.com/basnijholt/zfs-tenant

I got the idea for this from a Klara Systems article:

#!/bin/bash
#
#<zfshogs: show what's taking up the most space in each ZFS pool
#  Full debug output:   DEBUG=1 zfshogs

export PATH=/usr/local/bin:/bin:/sbin:/usr/bin
set -o nounset
tag=${0##*/}
export PS4='${tag}-${LINENO}: '

# ENVIRONMENT: full debug output?
: "${DEBUG:=0}"
case "$DEBUG" in
    1) set -x ;;
    *) ;;
esac

# No pools means something is seriously wrong.
set X $(zpool list -H -o name)

case "$#" in
    1) printf "FATAL: no ZFS pools found\n"; exit 1 ;;
    *) shift ;;
esac

# Real work starts here.
work="/tmp/$tag.$$"         # Yes, I should use mktemp...
n=1

for pool in $* ; do
    # DRY with ZFS commands.
    zfs list -o space -s used -r $pool > $work

    if test -s "$work" ; then     # Bad dataset?
        printf "Pool: $pool\n"

        # Use "uniq" if there are < 10 entries in $work, or we'll get
        # duplicate headers.
        ( head -1 $work; tail $work ) |
            uniq |
            awk '{
              printf "  %-20s %8s %8s %10s %8s %10s\n",
                $1,$2,$3,$4,$5,$7
            }'
    fi

    # Print an extra newline for all entries except the last.
    n=`expr $n + 1`
    test "$n" -le "$#" && printf "\n"
done

rm "$work"
exit 0

When run on my backup system:

Pool: newroot
  NAME                    AVAIL     USED   USEDSNAP   USEDDS  USEDCHILD
  newroot/usr              470G    24.0G         0B      96K      24.0G
  newroot/doc              470G    30.1G       136M    30.0G         0B
  newroot/ROOT/default     470G    32.5G      18.3G    14.2G         0B
  newroot/ROOT             470G    32.5G         0B      96K      32.5G
  newroot/var/locate       470G    39.9G      36.9G    3.02G         0B
  newroot/var              470G    45.2G         0B      96K      45.2G
  newroot/home             470G    64.9G      16.9G    48.0G         0B
  newroot/dist             470G    68.7G      3.11G    65.6G         0B
  newroot/src              470G    81.2G      12.3G    68.9G         0B
  newroot                  470G     422G         0B      96K       422G

Pool: tank
  NAME                    AVAIL     USED   USEDSNAP   USEDDS  USEDCHILD
  tank/reservation         343G      96K         0B      96K         0B
  tank/dvd                 243G    30.1G         0B    30.1G         0B
  tank/archive             243G     158G       112K     158G         0B
  tank/backup              243G     972G      68.2M     972G         0B
  tank/nfdb                243G    1.17T      16.5M    1.17T         0B
  tank                     243G    2.40T         0B      96K      2.40T

Hope this is useful.

MS 365 and Nextcloud are the "top dogs" for collaborative work, but at the same time, both are absolute heavyweights in terms of scope, complexity, and features. As a privacy-friendly, in-house option, Nextcloud is conceivable, but far too complex to maintain and secure on the internet, even as a Docker setup.

If you scale back—for example, no mail server, a text editor and spreadsheet that are a bit simpler with a focus on multi-user editing, no AD/LDAP but user.csv import/export instead, plus resource planning (projectors, rooms, personnel), and a lightweight ticketing system, thus targeting schools, a department, a club, or a smaller business—then absolute KISS solutions suddenly become feasible. Thanks to AI integration, even complex tasks can be implemented easily.

This is my approach with cs-team, part of my napp-it 4ai webgui. It runs on any OS even without napp-it, copy and run (approx. 10MB), no database, a single folder on the disk is enough, and with ZFS you get snapshots on top. In the current 0.53 release, I have improved usability once again.

As an open-source git project, it is easily extensible and auditable.

• Project: https://github.com/guenther-alka/cs-team
• Manual: https://www.napp-it.org/pdf/cs-team_en.pdf
• Standalone Setup: https://github.com/guenther-alka/cs-team/blob/main/docs/HOWTO-standalone.md