ZFS Downside of ZFS (over BTRFS and in general)

With BTRFS I could do bash completion of my snapshot names during send/receive, the names were just folders.

With ZFS, there is no autocompletion if you use a script and pass snapshots as parameters. And if you could pass snapshot names as folders .zfs/blahblah, you'd get autocomplete, but zfs only takes pool/dataset@snapshot syntax.

The only autocompletion with ZFS is if you don't use a script and just type zfs blah blah snapshot name.

So sad. 😒😞

💔
 
Maybe tag ?

#!/bin/csh -f
# zfs_tagged_snap.csh
# Usage:
# zfs_tagged_snap.csh local daily
# zfs_tagged_snap.csh local monthly
# zfs_tagged_snap.csh backup daily
# zfs_tagged_snap.csh archive monthly
........
.......
# --- Tag + horodatage ---
if ( "$MODE" == "monthly" ) then
set STAMP = `date +%Y-%m-01`
set SYS_TAG = "sys_m_${STAMP}"
set HOME_TAG = "home_m_${STAMP}"
else
set STAMP = `date +%Y-%m-%d_%H-%M`
set SYS_TAG = "sys_d_${STAMP}"
set HOME_TAG = "home_d_${STAMP}"
endif

usage

zfs_tagged_snap.csh local

or
...
And
zfs list .....

zroot/home/user@home_d_2025-12-31_21-05 90.4M - 43.7G -
zroot/home/user@home_d_2026-01-01_21-05 3.35M - 43.8G -
zroot/home/user@home_m_2026-01-01 3.34M - 43.8G -
zroot/home/user@home_d_2026-01-02_21-05 154M - 43.8G -
zroot/home/user@home_d_2026-01-03_21-05 847M - 44.2G -
zroot/home/user@home_d_2026-01-09_13-05 250M - 44.3G -
zroot/home/user@home_d_2026-01-10_21-05 146M - 44.4G -
zroot/home/user@home_d_2026-01-11_21-05
 
The snapshots are in /<poolname>/.zfs/snapshots

It is trivial to turn that directory listing into a function for shell completion.

Or you can just cd into that directory.
That actually does not work, according to AI, because you cannot use paths for zfs send.
 
according to AI,
According to AI, November 28th 2025 was a thursday.
According to AI, today is friday, Januar 13th, 2026. (I just asked it.)
According to AI, FreeBSD's default shell was bash, while in fact it's sh.
According to AI, ...BS!
AI = Artificial Imbecile

Flat learning curve's things sell best, because people misbelief, the curve stays flat, and flat ones bring you as far as steep ones without the effort to climb. Experience is not noted at the abscissa ("x-axis"), that's time, and effort, but at the ordinate ("y-axis"). So, if you wanna climb - gain experience (learn) - sooner or later you have to face a steep learning curve, bring effort yourself.
If you primarily trust a computer, because it promises no learning curve at all, which tells you genuine BS for over 50% of all times, and then ask others, which of the 50% are the BS, because you don't know for yourself, and then, if they tell you, argue with them, because you still trust the crap blathering machine more, you will stay at the abscissa, move unidimensionally, only: no effort = no experience, wasted time only.

But I'm blathering BS, because AI is such a nice thing to have - it's so comfy, right?
Question: What happens, when there is nobody left who can tell AI's answers from BS, you can ask?
 
With BTRFS I could do bash completion of my snapshot names during send/receive, the names were just folders.

With ZFS, there is no autocompletion if you use a script and pass snapshots as parameters. And if you could pass snapshot names as folders .zfs/blahblah, you'd get autocomplete, but zfs only takes pool/dataset@snapshot syntax.

The only autocompletion with ZFS is if you don't use a script and just type zfs blah blah snapshot name.

So sad. 😒😞

💔
Well fish does autocomplete zfs snapshot.
 
Just install the bash-completion-zfs package.
You are not reading what I've written in the original post. zfs autocompletion works if you just type zfs send/etc. Autocompletion does not work if you type ./backup_script_zfs.sh zroot/home/user@date_time !
 
Autocompletion should magically understand your custom script takes a zfs dataset as argument?
 
Autocompletion should magically understand your custom script takes a zfs dataset as argument?
TBH I've read several times this thread because I didn't understand what OP wants exactly, then his message #11 left me really doubtful about the statement made in the first post, I find it hard to believe.
There is a possible misunderstanding somewhere I think, not sure that BTRFS or ZFS have anything to do with that.
May be too much expectation from the shell?

Here is something OP can do, get a list of your ZFS snapshots:
Code:
$ zfs list -t snapshot | awk '{print $1}'
If one wants something interactive then pass it to a fuzzy finder tool:
Code:
$ zfs list -t snapshot | awk '{print $1}' | sed 1d | fzy
Put the result in a variable that can then be used with zfs send command.
 
All I ever hear about BTRFS is the possibility of losing one's data and that's all I need to know about any downsides.

It sort of happened to me (let's talk about me, shall we?). Some years back I was yet not so wise, so I was using Garuda Linux with BTRFS. I made my backups with the latest Clonezila version. One day I destroyed the system somehow, so I needed to restore it from the backup, but the restoration rendered an unusable system and I stopped using BTRFS from that point on. I didn't lose anything of value. My data per se was backed up somewhere else using a more reliable FS. Now you know.

(I was following this thread just to have the opportunity to explain this little experience. Thank you, drhowarddrfine).
 
the number of people who have eagerly told us about btrfs's repair tools is orders of magnitude larger than the number of people we've seen need to repair a zfs.
 
the number of people who have eagerly told us about btrfs's repair tools is orders of magnitude larger than the number of people we've seen need to repair a zfs.
I actually suspect it's a problem with Linux more than a problem with BTRFS.
 
Back
Top