I am still waiting for the 0.8 release with the killer feature of encryption-at-rest. They take their time, but what they do is so important, it has to be right.

I've been using it on Arch Linux since mid-2017, and it's amazing. Much easier and more flexible to set up than LUKS/GELI. I hope FreeBSD will get Datto's encryption soon when they switch to ZoF (their ZoL fork)

Here is the FreeBSD announcement of their move to ZoL.

https://lists.freebsd.org/pipermail/freebsd-current/2018-Dec...

That much easier than typing "geli init", and "zpool create"? :)

No, it's not easier but it's vastly more convenient and flexible. You can encrypt each dataset with different keys, and ZFS allows you to unlock them on import or whenever you want to. You can send and receive them while encrypted. Also ZFS encryption means that I can finally encrypt external HDDs that I share between Linux and FreeBSD without having to resort to ugly hacks.

Where can I find more about Datto's work on encryption?

Why is that special and what can you do with it that you can’t do now with LUKS on the underlying partitions?

Many things... here are the ones I care about:

- you can have different keys for all your "partitions" without having to pre-allocate them

- you can send encrypted incremental snapshots to a host that doesn't have the key (for backups for instance)

- it's using authenticated encryption (as opposed to LUKS with XTS)

Can't these things be done with eCryptfs or EncFS?

> you can have different keys for all your "partitions" without having to pre-allocate them

I imagine its possible to create multiple encrypted directory hierarchies with different keys as they are needed.

> you can send encrypted incremental snapshots to a host that doesn't have the key (for backups for instance)

You can just rsync the encrypted directory hierarchy.

> it's using authenticated encryption (as opposed to LUKS with XTS)

From my quick search, do I understand that "authenticated encryption" is basically hashing or signing the ciphertext or plaintext to make sure that it wasn't altered?

> Can't these things be done with eCryptfs or EncFS?

Possibly, but ZoL/ZFS offers an integrated solution without any setup, etc. That's very appealing for most people.

As an admin I really don't want to have to write a big pile of scripts to do what I could trivially do with ZFS by just setting some zpool or zfs options.

EDIT: I don't know why, but people who haven't "lived" it keep underestimating just how much the convenience of "integration" means. This is not a slight, I just think that it's one of those things that you have to experience to appreciate just how much of a difference it makes.

Also how futzing with disk arrays so often causes data loss.

Storage is unforgiving and you absolutely want the simplest thing to set up - for data safety.

The problem is that when you go to do recovery, maybe years after the thing was set up, it turns out the software has moved on and works differently and your storage media are in a state where at least one has failed and maybe more are dodgy, and if you have set something up with a few different interacting layers it is super easy to do the wrong thing and lose data.

I’ve lost data to “clever” storage setups before and now I stick to the “happy path” (only run the most common, well tested configurations).

This is an excellent point. When working with the ZoL tools I really get the impression that they want to make the easy and safe(!) things easy, and the dangerous things near-impossible.

I don't have that much experience with ZFS/ZoL (truly-)edge cases, but it's very reassuring that they had the right mindset when designing the tools.

> you can send encrypted incremental snapshots to a host that doesn't have the key (for backups for instance)

Isn't this possible already by encrypting the incremental snapshots with a key of your choice, and then just storing that on the remote host?

Sure, but you can't "consolidate" them without re-transferring everything (typically differential snapshots)... whereas with native encryption, you just delete the snapshot.

It also has real potential as a cross platform, encrypted file system. Initially Linux/bsd - but potentially also windows and os x.

Performance

Theoretical performance because on a system with an SSD you don't notice any difference at all with or without LUKS encryption.

At least last I checked, performance was unfortunately pretty crippled through ZFS. The loss was on the order of 75% of sequential read/write.

Has anyone tried it out more recently? Any difference?

I'm still awaiting official TRIM support for SSDs. Last I checked, that was still a work in progress but coming close to release.

Also along that line, there's also work going on to make L2ARC persistent across reboots (which would be wonderful for starting up VMs hosted on zvols).

I heard that recent SSD s don't really rely on trim so it doesn't really matter, does it?

ZFS needs double digits of free space to be happy. SSDs need double digits of zeroed space to be happy. Overlapping these requires TRIM.

Hey, I'm curious, would you mind turning 'showdead' on and replying to my comment here? I'm shadowbanned on here and would sometimes actually like replies in discussion with interesting comments like yours. Thanks.

You don't need it but you want it.

SSD's don't rely on trim, so you don't need them. It has still impact on performance and longlivety of the SSD. Depending on the usage patterns, the effect can be large or nonexistent.

From the release notes, it seems like a normal point release. I'm not seeing anything particularly noteworthy but this has hit the front page for some reason. What am I missing?

More context: https://marc.info/?l=linux-kernel&m=154722999728768&w=2

> 5.0 removes the ability from non-GPL modules to use the FPU or SIMD instructions

That’s a pretty good reason to stay on 4.x IMO. Talk about shooting yourself in the foot.

Optionally, we may expect distros like Ubuntu simply reverse that change to not ruin their own packages.

Also...

> My tolerance for ZFS is pretty non-existant.

Greg seems like a really pragmatic, nice and agreeable chap. Bet he’s a big hit at parties.

> Optionally, we may expect distros like Ubuntu simply reverse that change to not ruin their own packages.

If they want to earn the ire of the Linux kernel developers, sure. But they won't do that, especially if they employ kernel developers. That's a scummy thing to do.

It is complete bull to claim that loading and saving the FPU state makes a piece of code inherently derivative of GPL code such that it must itself be GPL. Calling that bluff may draw ire but it is not scummy.

Previous title had "...with Linux 5.0 compatibility". The significance of this is that 5.0 changed some interfaces used by ZFS to require GPL license, which ZoL can't call, which generated some discussion https://lore.kernel.org/lkml/[email protected]...

Wouldn’t it be possible to create an intermediate GPL licensed kernel-module which simply re-exported the relevant exports so that other kernel-modules could use the exports provided by this module instead?

It could have a neat name too, like “gplbridge” or whatever (all associations with License-trolls only partially intended). That way they wouldn’t have remove optimized code for Linux 5+ users.

Dirty, utterly pointless, but it would get the job done, right?

Imagine standing in court explaining to a non-technical judge and jury how this "bridge" transforms the copyrighted work into two fully separated works rather than a single derivative work. Do think it would work?

Personally I think one has a better time arguing that kernel modules simply interface with the kernel rather than creating a derivative work, thus making any module independent from the license of the kernel. The case law around "interfacing" is conflicting, but at least a few cases has gone in favor of the accused.

The original title mentioned that ZFS now have support for Linux Kernel version 5, which is something that have been discussed before since the kernel maintainers don't like the hooks that zfsonlinux uses, it was discussed on HN but I can't find it, the discussion sprung up because of this message: https://lore.kernel.org/lkml/[email protected]...

The previous discussion was here: https://news.ycombinator.com/item?id=19018185

There was a recent controversy in which the Linux kernel removed some functions which were being used by the ZFS module, but their replacement are "GPL-only" functions which cannot be used by the ZFS module. This release has a workaround for that, so it can be compiled for Linux 5.0.

(IIRC, the original title of this submission had " with Linux 5.0 support" at the end, indicating why this release is newsworthy, but I'm not seeing it anymore.)

That's how I like my file systems updates, anything not particularly noteworthy.

Which of zfs and btrfs is better on Linux? And which of the two works better with Windows (both have github drivers)? I'm looking to use on a personal computer on a partition shared between Linux and Windows

We have been using ZFS for a couple of years now with ubuntu on 4 machines managing a total of ~160 TB of raw storage and have had 0 problems. We chose it mainly because we wanted something very reliable with checksumming and because we consider it to be much more mature and stable than btrfs.

Prior to that we used proprietary RAID hardware that, while fast, did not have checksumming and was frankly a nightmare to manage.

If I had it to do over, I'd choose ZFS again.

I switched to FreeBSD solely because of ZFS, but if I had to use Linux it would be with ZFS too. It's much older and proven. Everything else seems to not be ready yet while ZFS has been stable for years and it keeps advancing ahead of the competition.

BTRFS can get exceedingly slow if you make lots of snapshots (even if you don't keep very many at a time).

ZFS works well for basic data storage and snapshots, but the deduplication has a ton of overhead and is extremely slow on hard drives. And there is no way to make a plain copy-on-write copy of a file without using the full deduplication mode.

I haven't tried either on windows directly, I've accessed them as a file share via a VM.

From my research:

ZFS is more stable, has the downside of not allowing expansion of volumes, and has the issue of not being upstreamed.

BTRfs has the option to expand volumes, is native to Linux, but has a wiff of unstability. Most notably with the persisting raid 5 write hole.

I haven't found a good choice yet. Though I think I'd go btrfs at the moment.

Zfs does allow pools to be expanded by adding vdevs.

What it doesn’t allow is for raid sets to be expanded by replacing with larger disks one at a time. This can however be done with mirrored sets. Add new larger discs to the mirror set, wait for resilvering, remove older smaller discs, done.

0.8 will also bring the ability to remove vdevs so effectively shrink a pool through a similar (but slightly different) process.

But even though you can add vdevs, it doesn’t rebalance the mirror. This means your entire pool, albeit larger, is still slower.

(Unless this is a change that will be brought about in 0.8, I haven’t followed that closely).

Not quite right - you absolutely can expand raidz vdevs by replacing the disks one at a time. What you can't do is increase the "width" of the raidz, or seamlessly rebalance data between multiple vdevs.

> ZFS is more stable, has the downside of not allowing expansion of volumes

No longer true. I’ve expanded volumes on Ubuntu with ZoL.

I hear btrfs is fine on single drives. ZFS is in general what you want to use if you care about your data, at least in RAID setups.

I imagine either should work fine over SAMBA (if that's what you have in mind for Windows). I know there's some work being done to get ZFS working on Windows, and I don't believe there's anything of the sort for btrfs.

At this point, what's Oracle getting from not making ZFS GPL?

They have their own RHEL derivative, would it make life easier for them as well (having an external community committed to keeping ZFS in the kernel tree)?

In my opinion, it is because they are freaking Orcale, they don't do anything for free. Heck they recently started charging for the Java runtime. Some that has been free for over 20 years.

I really hate to say this, but I wish IBM had bought Sun instead of Oracle. Even better I really wish Sun had managed to pivot and stay an independent company.

> Heck they recently started charging for the Java runtime.

On the contrary, they've open sourced the entire JDK for the first time ever, and are now offering the same JDK either completely free or with paid support, rather than the mixed free/commercial JDK as before. (I work at Oracle on OpenJDK, but speak only for myself)

Though I still run into software which doesn't like OpenJDK, complaining that the jar file was compiled with a newer version (and I have the latest OpenJDK version) which I assume means it wants the Oracle Java SE application.

It depends on which version you're using. As of JDK 11, OpenJDK and Oracle Java SE are the same.

I'm on OpenJDK 11.0, but I still get a "...compiled by a more recent version of the Java Runtime (class file version 53.0), this version of the Java Runtime only recognizes class file versions up to 52.0..." error.

JDK 11 supports class file version up to and including 55 (either OpenJDK or Oracle JDK, which is the same JDK under a different license).

Hmm...I wonder if the Java .jar in question is doing something funky, since I am running v11.

I thought if you used the Oracle JDK for commercial purposes you would be required to buy it from Oracle.

Now if OpenJDK is kept at parity with the OracleJDK that could work.

Not defending Oracle here, but I wanted to add some clarity.

Oracle will now only support current LTS versions of the Oracle JDK (as opposed to the OpenJDK), for something like 2 years. Basically requiring people to migrate to LTS releases relatively quickly.

If you can’t (larger orgs and others with requirements that delay those moves), then you’ll need to pay Oracle for a license.

Java (Oracle/Sun JDK) has never really been free, specifically, while I never worked with it, embedded JDK has always required a purchased license for distribution. The OpenJDK, on the other hand is a free OSS licensed distribution of Java.

In practice it doesn't really work like that. The vast majority of devs and companies using Java were not using an embedded JDK.

So for them, it's moving from a freely available JDK supported for many years, to a JDK that's changing every 6 months.

And the dust is far from settling on which alternative OpenJDK build is stable, reliable and free, long term.

I know that companies should pay for it, but things don't really work like that, see the OpenSSL fiasco.

At this point it may not even help. OpenZFS forked from Oracle ZFS like 10 years ago, so even if Oracle dual licensed it as GPL, the OpenZFS folks with a decade of non-Oracle code contributions, would have to contact every contributor for permission to re-license as well.

Starting with this would help.

Didn't VLC do this? It's not impossible.

http://www.h-online.com/open/news/item/Relicensing-VLC-to-th...

> They have their own RHEL derivative, would it make life easier for them as well (having an external community committed to keeping ZFS in the kernel tree)?

Oracle Linux uses Btrfs, and Oracle as a company puts more resources into Btrfs than they do ZFS.

They've been committed to Btrfs for almost a decade now, and they're continuing to improve that filesystem and make it solid for their use-cases and their customers.

Well, I must say, they're not really doing that good of a job. Btrfs is still largely less stable than even ZoL git snapshots in almost every possible way.

Hell no, first class support for ZFS is a selling point, if it was GPL customers could go elsewhere to get that.

They don't seem to be offering that for OEL though.

Well, making it GPL is not necessary, just GPL compatible.

I still have a bad bug with those versions. Anyone else? https://github.com/zfsonlinux/zfs/issues/8396

Basically, when serving NFS from a Linux-ZFS the client can read/write/seek fine, but on-demand paging sometimes fails (the same way it is supposed to fail when the file has been deleted server-side, but without any activity on the server).

So for example if you /usr is NFS emacs startup results in a bus error. The error rate increases with server uptime.

I tested ext2fs with the same linux kernel on the server and same clients - problem goes away. I use about the same ZFS version serving the same files from FreeBSD-current, error goes away.

I cannot be the only one seeing this?

Does anyone know of a good practical guide for basic administration of ZFS on linux?

https://pthree.org/2012/12/14/zfs-administration-part-ix-cop... Here is a good one I've used.

I wonder if all the work to make ZFS compatible with Linux will help make it more portable to other platforms as well. I really want to be able to use it on OpenBSD, but the prospects were very low last time I checked.

The recent(ish) comment from FreeBSD seemed to suggest it doesn't. If I recall correctly they are switching to ZoL because it receives more frequent bug fixes but they expect to have just as much work porting each update to FreeBSD as they currently do with the Illumos builds.

FreeBSD isn't "switching" to ZoL but it's a consolidation of effort as the FreeBSD related personnel come on board to ZoL.

Right...I get I was condensing the facts somewhat for the sake of brevity but your expanded point isn't contradicting what I said. The end result is FreeBSD are migrating over to the ZoL code base.

I'm guessing from the way you're spinning things that you're not ok with this switch? Personally I don't care where FreeBSD pull their ZFS sources from as long as it's stable - and I have full confidence in them that it will be.

Anyone benchmark the affect the 5.0 kernel vector disabled stuff has?

Wrong title! Should be "ZFS on Linux (or ZoL) 0.7.13 Released". The "real" ZFS is still under Oracle's hand and the spinoff is OpenZFS.

But OpenZFS is the one that matters now, so usually when people say ZFS, they actually mean OpenZFS.

Definitely agree. It's easy for people to mix them up but we need to be clear.

I absolutely loooove ZoL and run it on all cluster nodes. Proxmox works beautifully with it. I really hope ZFS for Linux and the kernel can get along, because ZoL greatly enriches Linux usability in storage needs.

besides the fact it looks now it's zfs, on linux 0.7.13 xD which would be silly at best

9 years old, with 70 releases, and still not good enough for a 1.0 release, huh? Guess I'll wait until they think it is ready for production.....

Firstly this is ZoL, not ZFS.

And secondly version numbers are often a meaningless gauge of when something is production ready. In any production environment you'd need to thoroughly test any new technology (or even point releases of existing tech) before deploying to prod because regression bugs and undocumented behaviour is a real thing.

As an aside, I've been running ZFS since shortly after it's release and have ran it across 4 distinct operating systems in that time. It's honestly been one of the best pieces of engineering I've used in that time. To the extent that ZFS has saved me from total data loss (ignoring, for the moment, backups) on at least two separate occasions.

9 years and 70 releases is referring to ZoL.

I use ZFS.

I am mocking open source developers' terror of calling something a 1.0 release.

At the same time they say release numbers aren't an indication of quality their actions tell us that release numbers matter a lot and that's why they are scared of calling something a 1.0 release.

> why they are scared of calling something a 1.0 release.

Given that ZoL doesn't support reflink (ficlone/ficlonerange; see also https://github.com/zfsonlinux/zfs/issues/405), and that ZFS is a CoW filesystem, that's pretty good reason not to have 1.0 release.

In other words, there is no way no use a key feauture, without enabling deduplication (that's exactly that feature, that requires heaps of RAM).

The idea I guess is that many project historically use the power of the decimals to indicate major from minor versions.

That’s it.

This ”scared” and ”terror” talk is a bit unnecessary as the only one interested in numbers in a version no. is someone selling it.

Linus is mocking this very fact by arbitrarily raising the kernel version.

> 9 years and 70 releases is referring to ZoL.

Wow time flies! Feels like only yesterday I was reading about the inception of that project.

FreeBSD and SmartOS have rock-solid ZFS.

I use ZoL and FreeBSD+ZFS almost on every single system I own, and it's as reliable as a filesystem can be. Btrfs and friends are still miles away from this level of reliability, imho. Heck even git snapshots of ZoL have never failed me, except once where they changed some file structure and I had to migrate a few datasets using unstable features.