EXT4 Gets A Nice Batch Of Fixes For Linux 5.8

[Old Grouch]

There are words, and there is a letter, but there also be words, and there be a letter...

R

[AndyChow]

How long you are using Linux? (I'm using it since 1991)

Hahaha, no, you weren't. To do so, you would have needed to manually compile the kernel under minix, and have the exact same hard-drive model as Linus Torvald, since the hard-disk parameters were hard-coded. In 1991, there were maybe 10-20 people in the world playing around with linux, and they were all minix academics.

But if what you claim is true, feel free to provide proof.

[kreijack]

I'm genuinely interested to hear why I'd want ZFS-likes on a desktop? What does it give me?

Good question. I will try an answer listing the advantages of zfs/btrfs:
1) cow filesystem (is not an advantage, but see next points)
2) checksum of the data block (depends by point #1)
3) cheap snapshot (depends by point #1)
4) integrated device management (is not an advantage, but see next points) with support of different raid profiles and/or multiple copy of data
5) scrub/resilvering/self healing: the system can rebuild corrupt data from a good copy (depends by point #2 and #4)
6) easily of growing/shrinking of filesystem (depends by point #4) [with or without adding/ removing devices]
7) send/receive, which helps for backup

If you are not interested in snapshot and "self healing", ext4 or xfs are a better alternative. I think that doesn't exist the perfect filesystem. Sometime it does exist a best filesystem for "my" use-case.

[kloczek]

How does that work with full disk encryption?

You mean zpool encription (wole pool of disk which are members of the ZFS pool)
Encritpion is part of the ZFS from more than decade. On Linux (ZoL ->ZFS on Linux) it has been ported IIRC 4 or 5 years ago.

[kloczek]

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.

I did not said that btrfs does not support RO and RW snapshots. I said every snapshot in case of btrfs must be mounted ex plicit which poluted mount table. Snapshot is it state of the volume in exact point in time. Volume should be only RW resource which is mounted as regular volume which in ZFS semantics is clone.

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.

It is not the limit. It is useless idea. Placing snapshot is consequence of the fact that each btrfs subvolume has no mountpoint as part of properties. In case of ZFS you can move around exact subvolume and its subvolumes like in case of ZFS by simple "zfs set mountpoint=/my_new/mountpoint mypool/mountpoint"
In case of ZFS you don't have even single entry in fstab becauise "zfs import mypool" mount all poll volumes in mountpoints whicha are described in zpool metadata. If you ghave thousands volumes it is only possible solution because updating fstab would be craziest thing ever.

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.

And not try to imagine move whole pool to other system or maintaining /etc/fstab with thousands volumes and for example 10-100 more shnapshots.

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-*

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.

I'm using snapper as well however its core it is fraction of the zfs kernel code. That code is so bloated and it is even written in C++ (total overkill).
In case of ZFS even autosnapshoter is just one shell script which is doing whole mangenent using metadata which can set by "
zfs set com.sun:auto-snapshot=true my/volume". Look on example. https://docs.oracle.com/cd/E19120-01...zuk/index.html
All is integrated into zfs command .. no external tools.

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.

Really try to install OmniOS or regular Solaris or zfs on Linuix than you will see how terrible badly is designed btrfs tooling :/
First time you will do this and will want to have ZFS ONLY around

[kloczek]

Hahaha, no, you weren't. To do so, you would have needed to manually compile the kernel under minix, and have the exact same hard-drive model as Linus Torvald, since the hard-disk parameters were hard-coded. In 1991, there were maybe 10-20 people in the world playing around with linux, and they were all minix academics.

But if what you claim is true, feel free to provide proof.

My first distribution was SLS with 0.9.9.x and first task was to upgrade it to Slackware with kernel 1.0.2.
You should be able to find my posts on kernel list probably starting from 1994 or next year try to search across kernel-list archives in 90's for "kloczek" .

[kreijack]

I did not said that btrfs does not support RO and RW snapshots. I said every snapshot in case of btrfs must be mounted ex plicit which poluted mount table. Snapshot is it state of the volume in exact point in time. Volume should be only RW resource which is mounted as regular volume which in ZFS semantics is clone.

In BTRFS a subvolume/snapshot are not required to be mounted explicitly. These have a natural placement in the filesystem. When I do a snapshot I set also where the snapshot is placed. And I can change this placement with a simple "mv" command (in this a subvolume is like a directory, you can also remove it with a simple "rm").

In my setup, I put the subvolume which I use (/ , /boot, /debian ) in the fstab. Their snapshot are in another subvolume which is also in the fstab. I have few entries in the fstab.

When I had to perform a rollback, I did something like:

# mv debian debian-broken
# mv debian-snapshot-20200606 debian

This without touching fstab. (yes I know that zfs can do with only one command...)

It is not the limit. It is useless idea. Placing snapshot is consequence of the fact that each btrfs subvolume has no mountpoint as part of properties. In case of ZFS you can move around exact subvolume and its subvolumes like in case of ZFS by simple "zfs set mountpoint=/my_new/mountpoint mypool/mountpoint"
In case of ZFS you don't have even single entry in fstab becauise "zfs import mypool" mount all poll volumes in mountpoints whicha are described in zpool metadata. If you ghave thousands volumes it is only possible solution because updating fstab would be craziest thing ever.

And not try to imagine move whole pool to other system or maintaining /etc/fstab with thousands volumes and for example 10-100 more shnapshots.

As stated above, in BTRFS a subvolume haven't be in fstab. I put it in fstab when I found useful to have a "bind". Anyway I don't see any big advantage to have the mountpoint as subvolume property instead of to be in the fstab (nor the opposite). In any case you have to set it. If it is done as

echo >>fstab [.....]

or

zfs set mountpoint...

is the same thing. And about the moving, I don't see any problem to cut&paste several lines between different fstab..

I'm using snapper as well however its core it is fraction of the zfs kernel code. That code is so bloated and it is even written in C++ (total overkill).
In case of ZFS even autosnapshoter is just one shell script which is doing whole mangenent using metadata which can set by "
zfs set com.sun:auto-snapshot=true my/volume". Look on example. https://docs.oracle.com/cd/E19120-01...zuk/index.html
All is integrated into zfs command .. no external tools.

I am not a snapper fan. However it does a lot more than zfs-auto-snapshot: e.g. it support xfs/ext4 + lvm< it has some form of integration with yast; it support snapshot at login time... It is unfair to compare these two tools.

Really try to install OmniOS or regular Solaris or zfs on Linuix than you will see how terrible badly is designed btrfs tooling :/
First time you will do this and will want to have ZFS ONLY around

I know that certain aspect of zfs are a lot better than btrfs (e.g. storage tiering and raid5/6). In other aspect BTRFS is superior (you can add, replace, remove device and reshape the filesystem easily). One limitation which seems strange to me is that ZFS doesn't support reflink, and also shrinking the filesystem has some limits.

IMHO these aspects are more valuable than the btrfs/zfs user command...

[Almindor]

Good question. I will try an answer listing the advantages of zfs/btrfs:
1) cow filesystem (is not an advantage, but see next points)
2) checksum of the data block (depends by point #1)
3) cheap snapshot (depends by point #1)
4) integrated device management (is not an advantage, but see next points) with support of different raid profiles and/or multiple copy of data
5) scrub/resilvering/self healing: the system can rebuild corrupt data from a good copy (depends by point #2 and #4)
6) easily of growing/shrinking of filesystem (depends by point #4) [with or without adding/ removing devices]
7) send/receive, which helps for backup

If you are not interested in snapshot and "self healing", ext4 or xfs are a better alternative. I think that doesn't exist the perfect filesystem. Sometime it does exist a best filesystem for "my" use-case.

Thanks for taking the time to list all these. What I'm getting in the end is that ZFS is a pretty complicated (overcomplicated IMO) filesystem that seems to try to solve problems that should IMHO be solved on non-FS layers. I don't think a typical desktop setup would benefit that much from running it.

Snapshotting is probably the most interesting aspect. Given the Linux kernel drama tho, I'll be staying with Ext4 for the foreseeable future.

[pal666]

Let's make EXT5 with all the features of ZFS and BTRFS.

we already have btrfs with all the features of zfs. and you can't just "add features" to fs, some features need complete rewrite

[pal666]

The only feature missing from ext4 is data Checksumming. Which is useless anyway because all disks do a crc themselves anyway.

disks can't checksum host memory contents, i.e. they can't catch all errors