Linked by diegocg on Thu 7th Nov 2013 22:19 UTC
Linux Linux kernel 3.12 has been released. This release includes support for offline deduplication in Btrfs, automatic GPU switching in laptops with dual GPUs, a performance boost for AMD Radeon graphics, better RAID-5 multicore performance, improved handling of out-of-memory situations, improvements to the timerless multitasking mode, separate modesetting and rendering device nodes in the graphics DRM layer, improved locking performance for virtualized guests, XFS directory recursion scalability improvements, new drivers and many small improvements. Here's the full list of changes.
Thread beginning with comment 576512
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[6]: Btrfs dedup
by Alfman on Sat 9th Nov 2013 07:17 UTC in reply to "RE[5]: Btrfs dedup"
Alfman
Member since:
2011-01-28

phoenix,

Thanks for pointing that out, somehow I focused only on ZFS-Fuse. I do not see ZFS kernel modules being supported natively by Debian, mint, centos, and I presume ubuntu, do any distros carry it natively?

I did see that zfsonlinux.org has modules for many popular distros (ie dep for debian, rpm for cent), but that's still technically the kind of 3rd party code/binary modules that I was trying to avoid. For those who don't mind this, then they can (and should) go this route. However let me just mention my own reasons for hesitating with this solution:

1. I believe I may be in violation of the CDDL & GPL licenses if I redistributed a kernel with ZFS to my clients.

http://arstechnica.com/information-technology/2010/06/uptake-of-nat.....

It's nearly inconceivable my clients would actually notice, much less care. I really have no idea if the copyright holders would care in the slim chance they got wind of it (ie oracle or linux devs). Maybe they wouldn't, but it'd still bug me if *my* business was in violation, you know?


2. My previous experiences with 3rd party modules (source & binaries) is that every single kernel update has the potential to break the 3rd party kernel code. The result means that module developers must keep on top of each and every mainline release (if distributing source), and each and every distro release (if distributing binaries), in order to not leave a gap in supported kernels. It wouldn't be the first time I've had to get my hands into the code to fix a temporary incompatibility with new kernels.

In fairness to zfsonlinux, I'm NOT pointing a finger at them, it's just an inherent problem with the kernel lacking a stable API/ABI. I may very well go with ZFS to gain it's functionality, but honestly using it as a root file system would make me nervous every time I upgraded the kernel on a server. I don't have this nervousness with say EXT4, so I'd probably keep root as an ext4 partition until ZFS is in mainline or if the ZFS kernel modifications were officially supported by the distro.

Edited 2013-11-09 07:34 UTC

Reply Parent Score: 3

RE[7]: Btrfs dedup
by jessesmith on Sat 9th Nov 2013 16:08 in reply to "RE[6]: Btrfs dedup"
jessesmith Member since:
2010-03-11

It is not a violation of the license if you distribute the ZFS module. The ZFS on Linux project has a nice FAQ section explaining this. If you merged the ZFS and kernel packages/source then it might be a violation, but distributing them separately is not.

As for breaking across updates, this is unlikely as the API does not change across security updates, it'll only be an issue across major upgrades. You're even safer if you use PPAs for Ubuntu-based distributions (including Mint) as the ZFS module is built specifically for your distribution and does not rely on the third-party upstream project.

Reply Parent Score: 3

RE[8]: Btrfs dedup
by Alfman on Sat 9th Nov 2013 23:57 in reply to "RE[7]: Btrfs dedup"
Alfman Member since:
2011-01-28

jessesmith,

"It is not a violation of the license if you distribute the ZFS module. The ZFS on Linux project has a nice FAQ section explaining this. If you merged the ZFS and kernel packages/source then it might be a violation, but distributing them separately is not."

That's my point exactly, unlike zfsonlinux.org, I'd be distributing them together. I guess I could always play semantic games like: Oh my, you need a good OS for your server, let me sell you one with linux on it. And later...oh remember that server that I provided you with, well it could sure use a ZFS file system now, and luckily 90% of the disk space was never partitioned...


"As for breaking across updates, this is unlikely as the API does not change across security updates, it'll only be an issue across major upgrades."

I disagree, modules often need to be pegged to a specific kernel. I was maintaining my own kernel with 3rd party FS modules (AUFS) the AUFS modules would regularly need to be updated, even when AUFS itself had no changes! Often times the latest AUFS version and the latest kernel versions weren't compatible; These were frequently trivial changes in the kernel, which I was able to track down within 10 minutes, but it still got tiresome. Granted, the zfsonlinux team may do an awesome job of keeping up with kernel changes, and I would factor this in.


"the ZFS module is built specifically for your distribution and does not rely on the third-party upstream project."

Right now I specifically looked for it on debian and mint, what's the package called?

I hope you understand I'm not trying to put down ZFS as a viable solution in many cases, but having conflicting open source licenses is troubling. I don't think it's just hypothetical either, this exhibits itself in unfortunate ways, like zfs modules not being available for all the platforms supported by distros - for example an ARM NAS box. It isn't my intention at all to start debating against ZFS supporters, I am very much interested in ZFS and I think it's great technology! I was merely trying to point out my own dilemmas.

Reply Parent Score: 2