[marcodiego]

I just skimmed over it but it looks like an interesting article. One thing the solution doesn't seems to be is simple or easy to use. Pipewire seems to be fixing the last remaining linux problems with multimedia, it is already a reasonable low latency kernel and will probably soon become even better once PREEMPT_RT finally lands. By coming by default on most popular distros, I hope using it will be invisible or simple too.

Nevertheless, as a linux user, I envy some features. I had apt break recently in a way that took 5 hours to fix with help from the people at #debian at oftc. A stable, mature and high performant filesystem with snapshots is badly needed. It could have reduced my time to a working apt again from hours to minutes.

[jcelerier]

When I was using apt based distros, Debian, Ubuntu, apt and dpkg would break all the time as soon as you went a little bit out of the canonical usage. In contrast I have yet to see Arch's pacman fail anywhere, even when used in non-ArchLinux places such as MSYS2

[dmz73]

Interestingly I have the exact opposite experience. Apt has never failed for me in the last 15 years but pacman fails all the time in both Arch derivatives and specially in MSYS2. With pacman you HAVE to keep updating at least weekly. MSYS2 often gets into state where it will no longer download updates and after going through all suggested fixes the only thing that works is to nuke it and start fresh. It doesn't help that pacman is designed to be used interactively so you can't just schedule reliable background updates.

[jcelerier]

> With pacman you HAVE to keep updating at least weekly

My record is updating a machine that was off for two years lol, it worked from the first try

Even for msys, I find that weird, I boot on win32 ... Once a month maybe ? And msys updates do work. Wild.

[dTal]

I am curious what your objections are to btrfs and ZFS? I know of some common ones, but I want to hear yours.

[marcodiego]

AFAIK, both btrfs and zfs are still slower than ext4 for most desktop use cases.

[diegocg]

Checksums and snapshots are so valuable I don't care about the performance impact. Modern file systems use more medatada so I expect them to be slower in metadata intensive operations, and the COW approach isn't good for every workload.

[RNCTX]

Depends. ZFS mirrors are very snappy.

Single disks were never a recommended option for ZFS, it's a filesystem designed for arrays.

[throw0101a]

> Single disks were never a recommended option for ZFS, it's a filesystem designed for arrays.

Not quite true IMHO. One of best features of ZFS is checksumming to ensure data integrity, where errors can be corrected if you have enough redundancy.

You certainly lose this feature with single disks, but you're not necessarily worse off than any other file system.

What ZFS gives you on a single disk is very convenient snapshots and very convenient (incremental) streaming of those snapshots to another system (via either a push or pull mechanism). Doing this with other file systems generally entail a lot more work and much less efficiency. btrfs can do it, but if you're using ext4, then you'll probably use rsync which has to walk the file tree to find changed files.

Also with ZFS and snapshots you can turn them into clones: writable copies. This allow boot environments were updates/upgrades can be done, and if things do not work out, you can boot back to the original setup:

* https://mwl.io/archives/2363

* https://vermaden.wordpress.com/2021/02/23/upgrade-freebsd-wi...

[chungy]

Probably even more crucial, setting compression=on is very likely to make ZFS performance even better than ext4, even on a single disk.

[Fnoord]

This and encryption seem mutually exclusive (for me with OpenZFS @ Ubuntu 21.04).

[RNCTX]

From using ZFS since ~2008, I have only ever lost one ZFS pool, and it was due to lack of scrubs (the array was created on a FreeBSD version before ZFS was integral to the installer, and despite upgrades the nightly scripts just never got overwritten, so the array was never scrubbed).

I can't say I've never lost an ext4 partition either, but I've never lost one under normal use without some sort of weird hardware issue causing data corruption.

By definition, without a redundant copy of the data the scrub can't fix anything.

> Creating a pool with no redundancy is not recommended...

https://docs.oracle.com/cd/E26502_01/html/E36219/storage-4.h...

[rabf]

You can also have datasets on a single disk where copies can be set to 2 or more so that checksum errors can be recovered. Each dataset in zfs can have a wealth of options such as compression that are specific to them.

[mixmastamyk]

Booting with a Live CD (recently USB flash drive), can have you back up and running in 15 mins or so. Even doing the install that replaces /usr etc only takes 30-40 or so.

[bluGill]

An adaptor so that jack/pipewire control programs can work with this would be a useful addition. I have no idea how to design on though.