EXT4 Gets A Nice Batch Of Fixes For Linux 5.8

[S.Pam]

"Using btrfs you have something like this using snapper but is crazy complicated"

Why so?

Btrfs subvolume snapshot /home /.snap/home-20200605

But if you want management of this you should simply use btrbk. You're free to set up any schedule you want. Snapper works too of course but I find btrbk easy and efficient.

[onlyLinuxLuvUBack]

We need a phoronix boxing match to settle real world fails handling: ext4fs vs zfs

[kloczek]

"Using btrfs you have something like this using snapper but is crazy complicated"

Why so?

Btrfs subvolume snapshot /home /.snap/home-20200605

But if you want management of this you should simply use btrbk. You're free to set up any schedule you want. Snapper works too of course but I find btrbk easy and efficient.

Because you must give mountpoint of the created snapshot.
In case of the zfs snapshot is the snapshot which is ALWAYS by definition R-O and is automatically availaibel in </vol/mount/point>/.zfs/snapshots/<snapshot_name>.
</vol/mount/point>/.zff is hidden directory soiit is not traversed by any commands like find or grep -r. You can unhide .zfs but that is not default which is very useful.

Btrfs snapshots semantics forces to main it somewhere and this causes that everyone are placing those snapshots in random places. It is not possible to hide snapshot in directory tree. In case of the ZFS you ALWAYS know where you can find snapshot. That is not the case with btrfs.

Because btrfs is forcing to mount snapshot somewhere usually you can find on typical system few/few tenths snapshots. In case ZFS because snapshot is not visible in mount list have thousands or millions snapshots NEVER is the problem

What is snapshot in case of the btrfs in case of the ZFS is clone. Clone is RW and creating it you need to specify snapshot name and mountpoint.

Try to list btrfs volumes without snapshots. With zfs it is possible to do that by "zfs list -t volume"
Try to list only snapshots. In case of the zfs it is just "zfs list -t snapshot".

Create snapshot on ZFS it is just "zfs snapshot </volume>@<snapshot_name>"

btrfs command syntax is crazy complicated . In case zfs all pool operations are done using zpool command and all volume operations using zfs. Syntax is so well designed that you can guess what you need to give as parameter.

[CochainComplex]

kloczek well code size does not really represent program complexity. i have no doubt that btrfs or zfs are great filesystems. im using btrfs on my nas if i wouöd have gone with freenas be sure i wouöd have choosen zfs.

but for my gamer desktop i just want to have a simple ext4 with raw performance and reliability. in case if poweroff as fsck is fine for me. if the game files are corrupted well then i will download them again.

for.my nas i m fine with btrfs and all the fancy new stuff snapshots or btrfs raid against bitrot (lol sounds like a rock band).

i dont trust the out of tree openzfs implmentation that is the only reason why im not using it on my nas with linux.

[pkese]

Because you must give mountpoint of the created snapshot.

...

btrfs command syntax is crazy complicated . In case zfs all pool operations are done using zpool command and all volume operations using zfs. Syntax is so well designed that you can guess what you need to give as parameter.

I appologize for the fact that btrfs is not exactly the same as ZFS. I'm sure they'd made it the same, if they knew you'd get so offended by that fact. Beacause feelings do matter.

[kloczek]

I appologize for the fact that btrfs is not exactly the same as ZFS. I'm sure they'd made it the same, if they knew you'd get so offended by that fact. Beacause feelings do matter.

IMO btrfs developers have no zfs experience and by this instead improving something they are forcing themselves to reinvent the wheel making terrible design mistakes which is very bad.
ZFS is not patented. It is open source solution There is no reasons to not mimic completely ZFS commands syntax by design something like btrfs and btrpool commands.
Nevertheless to provide 1:1 zfs to btrfs commands syntax btrfs snapshots semantics needs to be changed so such redesign will be not trivial.

[Almindor]

Small example. If your home directory is on separated zfs volume (which is normal) you can delegate from root operations like creating sub volumes, snapshots. You don;t need to switch to root to snapshot your home directory. One command you can enable autoshaphot you home directory every minute and keep last half hour snapshots?
How many times you've deleted accidentally something in your project and was not able to restore that? With zfs all what will be necessary to do will be "cd ~/.zfs/shanpshots/autosnaphot-<date>" and copy from last shapshot what you've just deleted.

Using btrfs you have something like this using snapper but is crazy complicated
You may need data protection but you have just one device. With ZFS you can do "zfs set copies=N </vol>" (where N is 2 to 128) to have data protection on single device. so even when you single disk will partially fail you will ha=ve greater chance to restore all data.

ZFS provides data integrity by storing all data and metadata checksums. Wit RAID it wi possible to find for example which part of the RAID1 is correct and which is corrupted.

ZFS does not need fsck. How many times after reboot you been waiting more than hour until fsck your ext/xfs volume to finish?

How many time s you've been in need to increase disk space by add another device? With pooled storage adding new disk to pool takes few seconds. Not backups. No copy. No reorganising MD/LVM. No restore.

Above is still not even 10% of things which is not possible to do with ext/xfs.

How does that work with full disk encryption?

[curfew]

Since when is Michael a foreigner? Last time I checked he was American, born and raised.

It's just his use of the language that's like a teenage girl being excited for having been chosen to write an article for the high school newspaper...

[kreijack]

Because you must give mountpoint of the created snapshot.
In case of the zfs snapshot is the snapshot which is ALWAYS by definition R-O and is automatically availaibel in </vol/mount/point>/.zfs/snapshots/<snapshot_name>.
</vol/mount/point>/.zff is hidden directory soiit is not traversed by any commands like find or grep -r. You can unhide .zfs but that is not default which is very useful.

btrfs has both RW and RO snapshot. It doesn't force where a snapshot is placed. So I don't understand (for this specific topics) why ZFS would be better.

In may case, my root is in a subvolume (called debian), and the snapshots of this subvolume are placed in the root of the btrfs filesystem.

Subvolume	Mount point
subvolume=debian	/
subvolume=/	/var/btrfs
subvolume=debian-20200605	/var/btrfs/debian-20200605
subvolume=debian-20200606	/var/btrfs/debian-20200606

where the last ones are the root subvolume snapshots. I can mount only the subvolume=debian and the snapshot are not visible. Other btrfs layouts put the snapshot inside the subvolume snapshotted. I personally dislike this layout, but I think that it is a matter of preference.

Btrfs snapshots semantics forces to main it somewhere and this causes that everyone are placing those snapshots in random places. It is not possible to hide snapshot in directory tree.
In case of the ZFS you ALWAYS know where you can find snapshot. That is not the case with btrfs.

Frankly speaking I don't really understand why the possibility to place a snapshot everywhere it is a limit. If you want to not see the snapshots, put it in a directory and ignore them. We already have directories filled with thousands of files (e.g. /usr/bin or /var/lib/dpkg/info/), and this is not a problem.

Because btrfs is forcing to mount snapshot somewhere usually you can find on typical system few/few tenths snapshots. In case ZFS because snapshot is not visible in mount list have thousands or millions snapshots NEVER is the problem

The number of snapshots limit on BTRFS (and ZFS) doesn't depends by the fact that a snapshot is visible or not. It depends by the fact that a snapshot implies a link between the original data and the snapshots. If you update the original data, you have to store both the new data and the old data, and the references to the two information. Of course the cost of this is higher when the number of snapshot is high.

BTW, for test I created 10000 snapshot of my root without any problem

ghigo@venice:/var/btrfs$ for i in $(seq 10000); do sudo btrfs sub sna -r / snap-debian-$i; done
Create a readonly snapshot of '/' in './snap-debian-1'
[....]
Create a readonly snapshot of '/' in './snap-debian-10000' ghigo@venice:/var/btrfs$ ls -dl snap* | wc -l
  10000
  ghigo@venice:/var/btrfs$ ls -ld snap*
drwxr-xr-x 1 root root 310 Apr 25 09:11 snap-debian-1
drwxr-xr-x 1 root root 310 Apr 25 09:11 snap-debian-10
drwxr-xr-x 1 root root 310 Apr 25 09:11 snap-debian-100
drwxr-xr-x 1 root root 310 Apr 25 09:11 snap-debian-1000
drwxr-xr-x 1 root root 310 Apr 25 09:11 snap-debian-10000
drwxr-xr-x 1 root root 310 Apr 25 09:11 snap-debian-1001
....
ghigo@venice:/var/btrfs$ sudo btrfs sub del -v snap-debian-*

What is snapshot in case of the btrfs in case of the ZFS is clone. Clone is RW and creating it you need to specify snapshot name and mountpoint.

Try to list btrfs volumes without snapshots. With zfs it is possible to do that by "zfs list -t volume"
Try to list only snapshots. In case of the zfs it is just "zfs list -t snapshot".

btrfs sub list -s lists only the snapshot. There is no a switch for listing only the subvolumes. Of course this is possible with the help of grep, but I have to admit that the "btrfs sub list" command is quite unfriendly.

Create snapshot on ZFS it is just "zfs snapshot </volume>@<snapshot_name>"

btrfs command syntax is crazy complicated . In case zfs all pool operations are done using zpool command and all volume operations using zfs. Syntax is so well designed that you can guess what you need to give as parameter.

Frankly speaking you are a bit ungenerous about the btrfs command. It could be better, but I don't think that it is so bad. I read you comment as the one of a person not familiar with btrfs tools. I have the same feeling when I use the zfs and zpool commands; but this is due to the fact that I am not familiar with these tools.

[Old Grouch]

Re: snapshots. I like the NILFS approach. Every COW operation is a potential snapshot. There's an issue with NILFS at the moment that generates kernel crashes on mounting NILFS volumes under certain circumstances, which means that I'm stuck on an old kernel, as it hits me 100% of the time on booting with newer kernels. I have an 'unusual' set up. So while the implementation has a problem right now, I like the approach. The COW journal loops, so I can read-only mount the filesystem to any point in the past covered by the journal: I don't need to take snapshots at regular intervals, although you can. Snapshots are then preserved from overwriting, but if you take too many, you run out of disk space.