[Raion]

https://www.phoronix.com/scan.php?page=n...-ZFS-Linux

Honestly with that in mind I feel there's no reason for the ZFS-on-Linux implementation to continue on trying to fight their uphill battle, since Linux essentially said they're not going to accommodate it. 

This kind of highlights the disconnect that I have a lot of developer communities. Egotism runs high and people don't want to accommodate others. It's a bit funny that Linus is acerbic as ever, just with less swearing.

[jan-jaap]

Egotism runs high and people don't want to accommodate others.

ZFS cannot be included in the upstream Linux kernel because the original ZFS that OpenZFS derives from is licensed under the CDDL, a license explicltly designed (by SUN) to be incompatible with the GPL. This is a fact and since only Oracle can change this situation, it's safe to say it's not going top go away. Given Oracle's habit of suing everybody and their mother, Linus is very right not allow OpenZFS anywhere near the mainline kernel and egoism has nothing to do with it.

Linus then basically claims that any effort spent on ZOL is wasted time, and that's an opinion. Everybody has an opinion, I don't care much about his in particular. The fact that ZOL is thriving despite this licensing BS should speak for itself, and for the relevance of ZFS on Linux. In fact, the ZOL project is doing so well that it eclipsed development of ZFS on BSD, the reason that FreeBSD is rebasing on ZOL. But that's an entirely different discussion.

I have been using ZOL since ~ 2015. I'm not religious about it, it simply serves my needs. There's nothing with a comparable feature set and proven reliability track record (at least not on Linux), so I don't see it go away anything soon.

[shrek]

I've been playing around with ZFS on OpenIndiana and I love it. In fact one of my home servers now runs OI. As per usual, crappy licensing is why we can't have nice things.

[jan-jaap]

Basically what I said, but better worded: https://arstechnica.com/gadgets/2020/01/...ight-dope/

[vishnu]

Sun was a great company and they saved themselves by coercing Oracle to buy them but Oracle is on the short list of evil companies I will never to do business with. I'm sure ZFS is great but in all the years I've been using Linux and the ext filesystem I've worn out innumerable Seagate and Western Digital hard drives but I've never lost a single file. I do keep backups but I've never had to use one (thanks smarmontools!).

[jan-jaap]

Have you ever had bit-rot though? Silent killer of data. I had a Linux file server for a brief time back in the late 2000's and found some of the game ISO's were mysteriously corrupting themselves. They looked fine, but were unreadable when retrieved later.

This. Photos that suddenly were damaged too. Server with quality parts: Tyan mainboard, Xeon CPU and ECC RAM, Linux XFS on LVM. Data at rest had simply suddenly "changed".

It is one of the main reasons I use ZFS. You can't beat this for comfort:

Code:

root@tuxedo:~# zpool status
  pool: tank
state: ONLINE
  scan: scrub repaired 0B in 0 days 13:20:40 with 0 errors on Sat Feb 22 15:20:55 2020
...

[Raion]

FreeBSD, in 12.x is currently the most stable implementation of ZFS with the latest features. If FreeBSD continues it's decline, however, I'm moving us to some kind of Solaris derivative long term.

[Donjon]

It is one of the main reasons I use ZFS. You can't beat this for comfort: <snip array status example>

It's probably worth mentioning that Linux mdraid also supports periodic scrubbing. On Debian it's the default behaviour.

Of course, your main defense against losing important files is making backups. All of the data I've lost over the years has involved not having a backup, and the vast majority was due to a PEBKAC error.

[jan-jaap]

It is one of the main reasons I use ZFS. You can't beat this for comfort: <snip array status example>

It's probably worth mentioning that Linux mdraid also supports periodic scrubbing. On Debian it's the default behaviour.

Of course, your main defense against losing important files is making backups. All of the data I've lost over the years has involved not having a backup, and the vast majority was due to a PEBKAC error.

mdraid can detect an error. ZFS can correct it. With mdraid I would probably have to map a corrupt inode to a file and manually restore it from backups.

mdraid can do snapshots, but they come with a performance penalty so you have to keep the numbers down. And allocate space in advance for them. With ZFS I have a schedule of hourly / daily / weekly / monthly / yearly snapshots. A couple of dozen per filesystem. For volumes shared with SMB to Windows clients, this integrates with the Windows 'previous versions' feature so the wife and kids don't even need the sysadmin (me) if PEBKAC happens.

With ZFS my offsite backup server can perform incremental, encrypted snapshots of the main server, and it doesn't need the keys to decrypt/mount the data. So my data is secure even if I can't guard the backup server 24/7. The offsite backup is primarily for disaster recovery: theft, fire or other catastrophic hardware and software failures.

ZFS has/had it's share of flaws too. The fact that it's forever going to be out-of-tree makes installation of a ZFS-only system more complicated than it should be. You have to make sure GRUB supports all features in your boot pool or risk an unbootable system. Until fairly recently the performance of encrypted ZFS was abysmal. You still can't enlarge a pool by simply adding one or more disks.

Ah well, in the end everything has it's pros and cons. At least there are some options to choose from. Enjoy them.