Ubuntu Plans To Make ZFS File-System Support Standard On Linux

An anonymous reader writes: Canonical's Mark Shuttleworth revealed today that they're planning to make ZFS standard on Ubuntu. They are planning to include ZFS file-system as "standard in due course," but no details were revealed beyond that. However, ZFS On Linux contributor Richard Yao has said they do plan on including it in their kernel for 16.04 LTS and the GPL vs. CDDL license worries aren't actually a problem. Many Linux users have been wanting ZFS on Linux, but aside from the out of tree module there hasn't been any luck in including it in the mainline kernel or with tier-one Linux distributions due to license differences.

Comments

Re:ZFS is nice...

[Anonymous Coward]

Why would you need nvidia drivers on a file server? Use Ubuntu Server, it's made for, well, being a server.

BTRFS is getting there

[DarkOx]

I don't why so many in the Linux community are so hooked on ZFS. BTRFS has a feature set that is rapidly getting there, its becoming more a more mature in terms of code that is already in the upstream.

Why not just put your energy there?

Re:BTRFS is getting there

[rl117]

It can certainly work when everything is working correctly. Have you tested its behaviour when things don't work correctly, for example by pulling the cable on one of the discs as it's running? Does it carry on running, does it transparently recover when you plug it back in? When I had a cable become unseated and the connection glitched, Btrfs happily toasted the data on the drive, and its mirror, and panicked the kernel whenever the discs were plugged in; I had to zero them out on another system before I could even try to reformat them. One of the major historical weak points has been that the failure codepaths were poorly tested, and this can come to bite you quite badly.

Re:BTRFS is getting there

[Bengie]

Nearly all of the original Sun devs that created ZFS in the first place, still work on OpenZFS full time and are paid to do so. OpenZFS is very actively developed. They have 2 or more presentations per year about all of the changes they're constantly making and some of the upcoming big changes. Currently they are focusing on standardizing ZFS between FreeBSD, Luminos, and Linux. It's a large refactoring effort to have all ZFS's code bases to live in the same tree. One OpenZFS code tree for all OSes. Everyone will be in sync.

While you can't shrink ZFS pools because they cannot do that atomically, and they refuse to do anything that allows the end user to shoot themselves in the foot, like leaving the FS in an inconsistent state, you can create a new pool that is smaller and import your larger pool into the smaller one, as long as it fits. Can't do it in-place, but you can do it. It just sucks to do that with a 1PiB+ pool. But who shrinks those?

Re:ZFS is nice...

[sexconker]

A typical home Linux server - AKA an old PC - won't have IPMI. Actual servers typically will have IPMI, but they cost $BIG_BUCKS$. And even then, IPMI is extremely limited.

On the Dell servers I bought a few months ago I can't do anything useful with it beyond power on/off or text-only console redirection over serial (over LAN) before the OS loads (I can get into BIOS and the RAID controller ROM, not much else).
Unless of course I pony up more cash for their iDRAC Standard/Pro/Enterprise/etc. shit. THEN I can get graphical console redirection, some storage space to flash firmware from, and even USB/optical drive redirection.

Re:ZFS is nice...

[evilviper]

I don't have a serial terminal, so having video output when needed is very important

So that's three-strikes... You're 1) using a regular PC as a server (no IPMI), 2) that PC doesn't even have a serial port to be used as an OoBM console, and finally 3) you've got some issue with the video card not even displaying text-mode. With all three strikes against your server, I just can't muster any sympathy for the predicament you put yourself in, relying on an unsuitable cheap piece of crap equipment.

In fact it's probably FOUR strikes... Presumably your video problem was an issue with KMS or similar, and 4) you didn't bother to figure out how to fix/disable/bypass it, and use plan old text-mode. Instead you went with the quickest (but obviously flawed and easily breakable) option of depending on a proprietary video driver. That's just not thinking things through. Reminds me of folks who has just a switchable PDU as their sole method of OoBM... works right up until they acidentally do a clean shutdown of a remote server.

Re:ZFS is nice...

[TheRaven64]

No. RAID isn't better handled at other layers. If you don't know about the filesystem semantics then you need NVRAM or journalling at the block level to avoid the RAID-5 write hole. RAID-Z doesn't have this problem. If you're recovering a failed block-level RAID, then you need to copy all of the data, including unused space. With ZFS RAID (all levels), you only copy the used data. There are numerous other advantages to rearranging the layers, including being a lot more flexible in the provisioning.

It's also a mistake to think of ZFS as a layer. ZFS has three layers: the lowest handles physical disks and presents a linear address space, the middle presents a transactional object store, and the top presents something that looks like a filesystem (or a block device, which is useful for things like VM disk images).