ZFS For Linux Finally Lands In Debian GNU/Linux Repos (softpedia.com)

prisoninmate quotes a report from Softpedia: It took the Debian developers many years to finally be able to ship a working version of ZFS for Linux on Debian GNU/Linux. For those not in the known, ZFS on Linux is the official OpenZFS implementation for Linux, which promises to offer native ZFS filesystem support for any Linux kernel-based operating system, currently supporting Arch Linux, Ubuntu, Fedora, Gentoo, Red Hat Enterprise Linux, CentOS, openSUSE, and now Debian. And it looks like their ZFS for Linux implementation borrows a lot of patches from Ubuntu, at least according to the changelog for zfs-linux 0.6.5.6-2, the version that is now available in the unstable channel for Debian users to install and test.

Comments

Bunking with Hans?

[Anonymous Coward]

I notice that this article was submitted by prisoninmate, yet the filesystem in discussion is ZFS, not ReiserFS.

What gives?

I'll probably hold out a while longer.

[Anonymous Coward]

An unstable version patched up with bandaids from the Ubuntu distro? Sounds like it's not ready for prime time yet.

Re:I'll probably hold out a while longer.

[rdelsambuco]

Exactly. Use the Mint version, instead.

Re:I'll probably hold out a while longer.

[Anonymous Coward]

Hence why they added it to the unstable repo and not the stable one.

Re:I'll probably hold out a while longer.

[ArchieBunker]

I'll use it with FreeBSD.

Re:I'll probably hold out a while longer.

[NIGGERpenisgoodPENIS]

Exactly. Use the Mint version, instead.

Since Mint is Ubuntu derived - how do you know there's much difference? I can't find any specific team working on this on Mint's web site. If there was such a team why wouldn't they submit patches back to upstream so Ubuntu could work on it too?

I mean I use Mint and so I would like to believe it's a better implementation ... but I don't know why?

Re:I'll probably hold out a while longer.

[zenlessyank]

um. uh. what the fuck. do you have some kind of mental problem? if I see you walking down the street with your UID on your shirt or car I will run you down. WHIPSLASH, PLEASE BAN THIS MUTHERFUCKER.

Re:I'll probably hold out a while longer.

[Anonymous Coward]

I've used ZFS for about ten years now on a Solaris 10 UltraSPARC box, still getting lots of patches for it and it will actually be supported for another five years or so. One day I'll probably switch to FreeBSD, but if I would switch to GNU/Linux it would probably be to Debian; I'm sure they will provide good support for ZFS.

Re:I'll probably hold out a while longer.

[Guspaz]

For varying definitions of "supported". Hasn't development of the old ZFS been at a standstill apart from critical patches, while OpenZFS has continued to evolve?

Re:I'll probably hold out a while longer.

[Anonymous Coward]

but if I would switch to GNU/Linux it would probably be to Debian

Why do you call it GNU/Linux and not GNU/ZFS/Linux? The filesystem is a pretty darn important part of an operating system.

Re:I'll probably hold out a while longer.

[Anonymous Coward]

Given that Solaris 10 is actually over 11 years old now I don't expect new features to be added; last major feature update we had was in 2013 and from then its mostly been bug fixes, but they are important too. Most of the new work is happening on Solaris 11 and the upcoming 12 release. And yes Oracle absolutely does a lot of new work on their version of ZFS, but since they don't make their changes public sticking to Solaris will become more and more of a dead-end. But I still expect to get a couple of years out if it, even though its clear that its not where the future is.

Re:I'll probably hold out a while longer.

[zenlessyank]

You are a fucking troll who thinks it is cool to have 2 sets of rules. Fuck Off Mr. Strangerman.

Re:I'll probably hold out a while longer.

[Anonymous Coward]

Oh do shut up, you're not fooling anyone.

Re:I'll probably hold out a while longer.

[Lisandro]

Why do you call it GNU/Linux and not GNU/ZFS/Linux? The filesystem is a pretty darn important part of an operating system.

It is. That's why Linux supports about 30 of them out of the box.

Re:I'll probably hold out a while longer.

[Anonymous Coward]

Why do you call it GNU/Linux and not GNU/ZFS/Linux? The filesystem is a pretty darn important part of an operating system.

It is. That's why Linux supports about 30 of them out of the box.

And 29 of them are shit. The only good file system on Linux is XFS and the only reason is because it's supported and continually developped by Red Hat.

Re:I'll probably hold out a while longer.

[Anonymous Coward]

Actually, XFS is supported by SGI.

RH may add patches, but the upstream is from what is left of SGI.

Re: I'll probably hold out a while longer.

[Anonymous Coward]

Don't let facts cloud the discussion.

Re:I'll probably hold out a while longer.

[thsths]

A lot of them are useless,but four are not:

ext4 may not be the most existing file system, but it is the default, solid, and good enough in most situations.

XFS is faster (especially for big files), but it has a few issues. reiserfs is quite good, and more space efficient for small files. Neither are clearly superior to ext4, unless you have specific requirements.

ZFS is taking it to the next level, and as such it may well be worthwhile. It remains to be seen how reliable it is on Linux, but in terms of features it is a clear winner.

Re:I'll probably hold out a while longer.

[Vertigo Acid]

OpenZFS was forked at version 28. Oracle has put out 5 versions since then, the most notable feature being native encryption. I wouldn't call it a standstill, but I wouldn't call it blistering speed either

https://docs.oracle.com/cd/E23...

Re: I'll probably hold out a while longer.

[ZeroZen]

Am I the only person who uses BTRFS?

Re: I'll probably hold out a while longer.

[Anonymous Coward]

They are up to 37 according to Wikipedia. I think that Oracle page is out of date.

Re:I'll probably hold out a while longer.

[Guy Smiley]

The ZFS encryption was basically finished before Oracle acquired Sun.

Re: I'll probably hold out a while longer.

[Anonymous Coward]

Am I the only person who uses BTRFS?

No. I use it on a backup server for Windows fileshares, of all things. I rsync from the mnt to the clone, then snap the clone off. I have two a day backups going back 3 years from when I replaced the drives as a preventative measure. Works wonderfully. I have full disk image backups too, but I never use them. Oh, you deleted/overwrote the wrong file? OK... just here's the prior version. Oh you screwed it up last year? Not sure when?... a quick bash script and I have an ls -l of all the "foobarIFedUp.doc"

Just don't run du on the root of the snaps...

I use it on vm hosts too, but have run out of inodes a couples times bc our SW devs were.... inelegant in their DB designs.

Re:I'll probably hold out a while longer.

[Anonymous Coward]

Actually as a black man I consider the n-word to be a badge of honor, a sign of times we have had to endure and the fact that we got through it no matter what. As a bisexual I see no reason to be ashamed of my sexuality or my slight preference for men because - for me - men are easier to relate to. You want to hate me for that?

How terrible of you to stereotype someone or assume that everyone who is irritable is necessarily racist or homophobic. Bringing biases into an unrelated discussion like this when they were not even on the table does not make you look strong, or intelligent. Maybe you should get over your ego rather than trying to act like the defender of all black and bisexual people. Not everyone hates you, because most people don't give a shit about you.

Re: I'll probably hold out a while longer.

[cthulhu11]

⦠all of them lame. Until this.

Re: I'll probably hold out a while longer.

[cthulhu11]

XFS over time can cause kernel mem fragmentation if you build with non-default yet documented parameters. Feh. Agree on ZFS features. When I had to downgrade to Linux I was speechless when I saw there wasn't a usable filesystem that even imagine implemented compression. Got 30x for syslog archives with ZFS. And the lameness of MD and LVM, being at least ten years behind Solaris.

Re: I'll probably hold out a while longer.

[Anonymous Coward]

Am I the only person who uses BTRFS?

Nope. We non-purist pragmatists spend less time on the forums though. I used OpenIndianna for zfs SAN and btrfs on linux. I would have stuck with OI if I could, but I had to support linux boxes anyway so after a year without btrfs issues I consolidated on Linux/btrfs. Been running it 5+ years without any of the horror stories I hear about online. Keeping your disks with 10+% space free seems to eliminate most issues on most filesystems anyway.

Don't Bother with ZFS

[Anonymous Coward]

If you want the benefits of ZFS use FreeBSD. It's a much nicer/cleaner OS than Debian or the other 3000 linux distros in use cases that require ZFS.

Re:Don't Bother with ZFS

[danbob999]

I hear that all the time, but why would I switch operating system only for the file system? Ever heard of someone switching to Linux to get ext4 support? Or to Windows to get NTFS support? Of course not. File system is a very minor component of an operating system these days. Except if I were building a NAS, I wouldn't even consider making a comparison of file systems when choosing an OS.

Re:Don't Bother with ZFS

[Billly Gates]

I hear that all the time, but why would I switch operating system only for the file system? Ever heard of someone switching to Linux to get ext4 support? Or to Windows to get NTFS support? Of course not. File system is a very minor component of an operating system these days. Except if I were building a NAS, I wouldn't even consider making a comparison of file systems when choosing an OS.

Go look up containers and jails? ZFS is more than just a filesystem as it can be used for situations with jails. That is a big difference.

Also without SystemD and with old fashioned init you get a much more reliable and production ready system

Re: Don't Bother with ZFS

[reg]

Some people would say that is the biggest strength of freebsd... In fact that is the primary concern of developers worried about moves to package the freebsd base system. Regards, -Jeremy

Re: Don't Bother with ZFS

[Anonymous Coward]

The os is much more than a file system AND containers/jails. Happy now? Sheesh.

Re:Don't Bother with ZFS

[Anonymous Coward]

Maybe but it doesn't support my hardware.

Re:Don't Bother with ZFS

[Kokuyo]

Isn't FreeBSD the OS where you have to deal with the same incompatibility bullshit as in Linux... just exponentially more so?

Call me pessimistic, but with my luck on Linux I don't even want to try FreeBSD...

Re:Don't Bother with ZFS

[NIGGERpenisgoodPENIS]

Isn't FreeBSD the OS where you have to deal with the same incompatibility bullshit as in Linux... just exponentially more so?

Call me pessimistic, but with my luck on Linux I don't even want to try FreeBSD...

If I was going to try any BSD it would definitely be OpenBSD especially for running a net facing server. For day to day use, browsing, email, getting work done, playing games, whatever, I plan to stick with Linux behind a NAT router.

Re:Don't Bother with ZFS

[Anonymous Coward]

yeah -- also, it's webscale

Re:Don't Bother with ZFS

[poet]

If you are building a server, then file system absolutely matters.

Ext4 is fine but limited and not nearly as mature or stable as XFS. When building a server that *matters*.

ZFS blows the doors off of anything the Open Source community has *ever* built (in terms of file systems). It has features that Linux users have been desperate for. For example, file system snapshots and rollbacks. Yes, you can do it with LVM2. Guess what? LVM2 sucks at it (in comparison to ZFS).

Re:Don't Bother with ZFS

[Anonymous Coward]

I hear that all the time, but why would I switch operating system only for the file system? Ever heard of someone switching to Linux to get ext4 support? Or to Windows to get NTFS support? Of course not. File system is a very minor component of an operating system these days. Except if I were building a NAS, I wouldn't even consider making a comparison of file systems when choosing an OS.

This "filesystem" was built to compete with NetApp basically. Comparing it to ext and NTFS is silly, those don't aim to turn your system into a storage appliance. That's what Sun wanted to do with it besides simply improving Solaris anyway, make a new class of storage server.

People "switch" (choose) operating systems all the time for... things an operating system does other than the filesystem, so why is that surprising. I've even heard people switch because of their UIs, crazy!

Re:Don't Bother with ZFS

[Anonymous Coward]

I hear that all the time, but why would I switch operating system only for the file system? Ever heard of someone switching to Linux to get ext4 support? Or to Windows to get NTFS support? Of course not. File system is a very minor component of an operating system these days. Except if I were building a NAS, I wouldn't even consider making a comparison of file systems when choosing an OS.

For NAS, its a killer RAID filesystem. It's a bit of a memory hog, but the anti-corruption and snapshotting features are great. The on the fly compression doesn't save much space for media files, but that's handy to have also.

My only gripe is how tricky it is to add more drives to the raid. I don't know if I would switch operating systems to have it, but I'm really liking it and I wouldn't want to go back to another filesystem.

Re: Don't Bother with ZFS

[Anonymous Coward]

Have your heard of this new virtualizion thing? Chroot is not that important of a feature any more.

Re:Don't Bother with ZFS

[mlts]

It can be argued that testing the OS as a gestalt is a good thing. One good idea is how AIX does releases. You have your OS revisions and your APARs as patches, but you have technology level updates as well, which are not truly OS updates per se... but a snapshot in time where all packages and updates have been thoroughly regression tested. It would be interesting to have something similar on a quarterly basis. This is sort of handled by OS updates like RHEL 6.8 which was recently released, but would be something that would be more guaranteed to happen at a time of the year, so every so often, there is a solid base to start at for OS imaging.

Re:Don't Bother with ZFS

[mlts]

It would be interesting for the ability to add more drives dynamically, perhaps with a new RAID type that can work with dynamic adding and removing of drives, minimizing the time the array is in a degraded state.

My "ideal" of a filesystem that sits on BSD is EMC Isilon's OneFS or NetApp's WAFL filesystem. This not just offers what ZFS has, but the ability to link other nodes via Infiniband and use their filesystems, presenting a filesystem which is redundant across drives, and redundant across nodes. If a drive fails on an Isilon cluster, it can be configured to rebuild itself, except with less disk space, so redundancy is preserved. I've even encountered severely neglected Isilon clusters that have had over half their drives dead, and the only reason the users noticed was that they ran out of disk space.

Re:Don't Bother with ZFS

[Anonymous Coward]

To build a Fiberchannel target backed by ZFS on a FreeBSD box? Can't do it on Linux and it's a hell of a lot cheaper for the lab than a NetApp.

Re:Don't Bother with ZFS

[Anonymous Coward]

Because ZFS is actually part of the kernel structure of FreeBSD. Linux puts the filesystem in userspace which makes ZFS in userspace inefficient. (Hell all filesystems in user space are inefficient, but ZFS doubly so because of what ZFS is.)

ZFS, in short is a bullet-proof file system, if setup correctly. Unfortunately the VAST majority of use cases are overkill. A proper ZFS setup would require no less than 4 mechanical drives and 8GB of RAM. Just for the file system. Because underneath ZFS is essentially a very smart software RAID 6 and journaling system. So you can pretty much kill one drive in a 4 drive system and it will still function as if it was still there, no "degraded mode" like in a hardware raid. Then when you replace the drive, or upgrade it to a larger drive it just works seamlessly, no week-long rebuilds with impaired performance.

Compare that to ext2/ext3/ext4/UFS/exFAT/NTFS which are nothing but filesystems, some with journaling.

Re: Don't Bother with ZFS

[Anonymous Coward]

What you say sounds reasonable on the surface, but are you sure it isn't bullshit? One of the main reasons to put code in userspace is to avoid expensive kernel calls.

Re:Don't Bother with ZFS

[Anonymous Coward]

I've even encountered severely neglected Isilon clusters that have had over half their drives dead, and the only reason the users noticed was that they ran out of disk space.

If people run a cluster like you mention and don't monitor it, then they should not be allowed to run said cluster, purely based on lack of basic maintenance skills - what else might be malfunctioning/misconfigured ...

Re:Don't Bother with ZFS

[JoeMerchant]

But wait, during the decade or so that ZFS was "almost ready," wasn't there a functional transactional file system option with a less-well-known name?

I'm trying to remember what it was - and also flush out a believer who can tell us: "X" was doing this 5-6 years ago and has been actively improving since then, ZFS is just a better known name, not a better system.

Anybody remember that one?

Re: Don't Bother with ZFS

[inode_buddha]

He's not BS'ing. ZFS on linux has been tried as a userspace filesystem (via FUSE, among other efforts...), and its nowhere near as good as a native, in-kernel implementation. Doing the FS in userspace actually costs more in raw performance.

Re:Don't Bother with ZFS

[NIGGERpenisgoodPENIS]

It can be argued that testing the OS as a gestalt is a good thing. One good idea is how AIX does releases. You have your OS revisions and your APARs as patches, but you have technology level updates as well, which are not truly OS updates per se... but a snapshot in time where all packages and updates have been thoroughly regression tested. It would be interesting to have something similar on a quarterly basis. This is sort of handled by OS updates like RHEL 6.8 which was recently released, but would be something that would be more guaranteed to happen at a time of the year, so every so often, there is a solid base to start at for OS imaging.

I can see how that might be desirable in terms of support - you have a known system with known qualities. In every other way though, I'll take a rolling release system any day.

Re: Don't Bother with ZFS

[Anonymous Coward]

None of the BSDs use sysvinit.

Re:Don't Bother with ZFS

[Anonymous Coward]

what, butterfs?

Re:Don't Bother with ZFS

[UnknownSoldier]

> ZFS, in short is a bullet-proof file system, if setup correctly. ... Because underneath ZFS is essentially a very smart software RAID 6 and journaling system.

Well, considering hardware RAID has a silent corruption bug, I'd say it more then "essentially" :-) Especially with Raid-Z2 and Raid-Z3.

See Pages 13 .. 18
ZFS The Last Word in FileSystems

Measurements at CERN
* Wrote a simple application to write/verify 1GB file
* Write 1MB, sleep 1 second, etc. until 1GB has been written
* Read 1MB, verify, sleep 1 second, etc.
* Ran on 3000 rack servers with HW RAID card
* After 3 weeks, found 152 instances of silent data corruption
* Previously thought âoeeverything was fineâ
* HW RAID only detected âoenoisyâ data errors

Re:Don't Bother with ZFS

[Anonymous Coward]

ZFS is available in FUSE, as well as an in-kernel implementation (ZFSonLinux).

And a "proper" ZFS setup requires only 2 drives in mirrored setup.

Re:Don't Bother with ZFS

[Anonymous Coward]

And while FreeBSD now has a packaging system for their ports collection...

Ok, just what in the living fuck are you talking about??? What century do you think you are in?

Re:Don't Bother with ZFS

[dbIII]

I hear that all the time, but why would I switch operating system only for the file system?

The obvious reason would be for a file server. Other situations are not so obvious, but as for minor - unlikely.

Re:Don't Bother with ZFS

[rl117]

Simply because it's a *killer feature*. It does things which no native Linux filesystem can offer, even when coupled with LVM and RAID. It takes all of these and replaces them with something that's simply better, more robust and easier to manage. And which is also properly documented with a good number of tutorials and best practices documented clearly.

I'm one of the people who migrated to FreeBSD pretty much because of ZFS, initially for a NAS but now also on other systems. Not the only consideration, but it was the primary one. I used Linux-ZFS to initially use ZFS on Linux and migrate the data from LVM/ext4, but later transferred the disks to the NAS. A simple "zpool import" was all that was required to do so; few filesystems have that level of cross-platform interoperability (ignoring awful ones like FAT). Everything was already mounted in the right places as well!

Linux does not offer anything comparable, so if you want those features then switching operating systems to one which offers them natively makes sense. I'm going to have a play with Ubuntu 16.04 on ZFS in the next few weeks, and might well end up using it, but it's still less mature and well integrated so I doubt it will replace ZFS on FreeBSD for me anytime soon, but might supplement it--I'll at least be able to "zfs send" backups to the FreeBSD ZFS server.

Re: Don't Bother with ZFS

[loufoque]

If you had actually used systemd, you'd know it makes your services more reliable, not less.

Re:Don't Bother with ZFS

[fisted]

For example, file system snapshots and rollbacks

NetBSD does this in a filesystem-agnostic way with its Filesystem snapshot device

Why build the functionality into one particular filesystem? Oh yes, poor design.

Re:Don't Bother with ZFS

[Wokan]

If I wanted the experience of maintaining a BSD, I'd switch back to Gentoo Linux.

Re:Don't Bother with ZFS

[phoenix_rizzen]

Uhm, no.

ZFS-on-Linux is the project that creates a kernel module for all the ZFS bits, and integrates the filesystem into the Linux storage stack.

It's not as stable and reliable as the FreeBSD setup, but it's a geek of a lot more stable and performant than the old FUSE-based setup on Linux .

Re: Don't Bother with ZFS

[cthulhu11]

Because some of us need to run applications

Re: Don't Bother with ZFS

[cthulhu11]

Agree wholeheartedly. Or the blindingly obvious need for compression, or Linux's continuing refusal to integrate volume management, RAID, and filesystem.

Re: Don't Bother with ZFS

[cthulhu11]

There's a name for what you want: Ceph. ;)

Re:Don't Bother with ZFS

[danbob999]

Oh yeah sorry, I forgot. Most servers out there do not use ZFS. And they still perform stuff that matters.

Re: Don't Bother with ZFS

[pnutjam]

shhh... Don't wake up his brain, he's been sleepworking for years.

Re:Don't Bother with ZFS

[pnutjam]

Btrfs is already the default file system for SuSE. I believe it is on par with ZFS and has a better roadmap. It's also GPL, which is ZFS's biggest problem.

Re:Don't Bother with ZFS

[Wolfrider]

--ZFS is much more flexible with mirrored pairs. Build a 5- or 6-disk RAIDZ2, and you have to add the same number of drives ( with the same capacity, e.g. 6x1TB + 6x1TB ) to double the RAID capacity properly and keep your I/O throughput sane.

--However, if you start with a mere 2-disk mirror, you can keep adding mirrored pairs much more easily. Example: Start with 2x1TB WD RED NAS drives in a mirrored pair. Create a mirrored zpool with both disks. You start with ~1TB of redundant mirrored storage, with ~2x the speed of 1 drive for read operations since ZFS can pull blocks from either disk.

--Now add another 2x1TB mirrored pair to the zpool (there are plenty of articles online on how to do this, but I will refer to the official docs):
http://docs.oracle.com/cd/E192...

--Wait for resilver to complete: ' zpool status ', and now you have a RAID10 with ~2TB of redundant writable space. You can't survive losing *both* disks in a given mirror "column", (SO BACKUP!) but you *could* lose 1 disk from either mirror set and still be up and running with a "degraded" pool.

--Keep the drive sizes reasonable, and recovery time will be minimized since ZFS only has to resilver the "used" blocks in the filesystem, not the whole disk. (Another big advantage over RAID5/RAID6.)

--Caveat: You can't "shrink" the pool without destroying it and recreating it, but overall that's pretty easy to get used to once you consider all the benefits of the filesystem. Plan your pool capacity accordingly, and allocate entire GPT-labelled disks to the pool. You can expand on-the-fly with negligible "downtime" -- (the pool is still quite usable, but I/O operations will slow down the resilvering.)

Re:Don't Bother with ZFS

[dave420]

Btrfs is not on on par with ZFS. Not even close.

Re: Don't Bother with ZFS

[Coren22]

Have you heard of this new docker thing? Virtualization is so outdated, you make extra copies of the OS?

Re:Don't Bother with ZFS

[Anonymous Coward]

Btrfs is not on on par with ZFS. Not even close.

Honest question... Why not? Specifically for "regular" people/business use. The places that buy a Dell box, throw in 4 hard drives off NewEgg/Amazon and use 2TB $100 USB3 drives as their off site backups (at best).

Re: Did you know?

[Sasayaki]

"The lack of evidence for this claim is evidence of a cover-up to hide the evidence of this claim, and is therefore evidence for this claim" is basically the prime argument for every conspiracy theory argument ever.

Re:This is great news!

[Anonymous Coward]

You can expect a Hillary America to have copyright and patent laws changed to prevent further development of Linux.

Love ZFS still hoping for BTRFS

[geek]

I love ZFS on FreeBSD. Its works amazingly well. I tried it on Linux (Antergos lets you use ZFS on root if you're interested). My experience with Linux was less satisfying. It is an absolute memory hog. I was using 8 gigs of RAM at all times. Ordinarily I don't mind this, RAM is there to be used afterall. But on the same box with FreeBSD I rarely broke 2 gigs of RAM used and the same goes with any Linux distro and BTRFS.

The features of ZFS are great and you can't beat the speed and stability but I really hope BTRFS gets caught up as it seems to be a better filesystem ideologically.

Re:Love ZFS still hoping for BTRFS

[Anonymous Coward]

Uhm, you know those things are mostly caches? And the seconds it's needed by some program it drops it? Unless you're talking about something like the deduplication support then memory usage is not something you should get to hung up on. I have lots of servers running ZFS, some on as little as 512 MB of RAM and they are fine.

Re:Love ZFS still hoping for BTRFS

[fluffernutter]

I played with ZFS for a little awhile as a backup pool. The snapshotting is very nice, but I ended up using ext4 instead for my purpose because nothing is extendable. A modern FS should have extendable volumes.

Re: Love ZFS still hoping for BTRFS

[Anonymous Coward]

"I have lots of servers running ZFS, some on as little as 512 MB of RAM and they are fine."

You know nothing of ZFS.

Re: Love ZFS still hoping for BTRFS

[Anonymous Coward]

You know when you say things like that you should also add why the person doesn't know this or that. Otherwise it's not that much of an argument. ZFS has been around for some time now, and back in 2004 or so when ZFS started to be usable it was not at all unusual to have servers with less than a gigabyte of RAM. Maybe they started screwing with it when they ported it to Linux I don't know, but ZFS was designed for and can absolutely run on fairly small amounts of RAM.

Re:Love ZFS still hoping for BTRFS

[Anonymous Coward]

If they copied the implementation I last used in Solaris, ZFS doesn't use the page cache, it uses its own more advanced caching strategy called ARC. So utilities that factored out page cache usage won't automatically account for ARC usage, even though it's hooked into the same kernel routine that gets called when memory is low.

So if memory usage between the systems is off by THAT much, that's the first thing I'd look at.

Re:Love ZFS still hoping for BTRFS

[Anonymous Coward]

ZFS's whole thing is extendability. Maybe you were using it wrong?

Re:Love ZFS still hoping for BTRFS

[Anonymous Coward]

Linux and BSD accounting for memory currently in use for ZFS ARC differs.

Re:Love ZFS still hoping for BTRFS

[Anonymous Coward]

BTRFS is dead in the water. Oracle pulled out and doesn't give a shit anymore since they acquired ZFS.
Seriously the only 2 viable options on linux are XFS and ZFS (since a good chunk of work was already done).
No one sane of mind would use BTRFS on a production machine.

Re:Love ZFS still hoping for BTRFS

[Anonymous Coward]

"And the seconds it's needed by some program it drops it?"

On FreeBSD or Linux, maybe it does this. On Solaris, this what the documentation claims happens, but reality is different. You will encounter failures in malloc() once ZFS has decided to grab nearly all of your memory. It has a thread that only wakes up periodically to check if it should relinquish some RAM. If you happen to request more memory than ZFS has left you, you will be denied.

This was for Solaris 10, maybe it's been fixed in 11. In 11 though, you can adjust the ARC size without a reboot, so it's less of a problem.

Re:Love ZFS still hoping for BTRFS

[Anonymous Coward]

Maybe you were using it wrong?

Almost certainly. I've yet to see the Linux noob who wasn't tragically confused upon encountering a file system meant for something other than grandma's Facebookin' laptop.

A modern FS should have extendable volumes.

Bingo.

A modern FS shouldn't be a one-disk kingdom, blissfully unaware of anything outside itself and requiring hardware or yet another package to handle spanning disks.

Re:Love ZFS still hoping for BTRFS

[fluffernutter]

No ZFS's thing is snapshots. Once you create a ZFS disk pool I could find no way to add a disk to it to make it bigger.

Re:Love ZFS still hoping for BTRFS

[Lord Crc]

Just create another vdev with the new disks and add it to the pool. Voila, more space in the pool.

Re:Love ZFS still hoping for BTRFS

[Anonymous Coward]

If you got the luxury of choosing a filesystem based on ideology, then you probably don't need ZFS or work on mission-critical systems.

Re: Love ZFS still hoping for BTRFS

[Anonymous Coward]

You can configure ZFS to run on very little memory, but write performance will go to crap and read performance will also take some hit due to the random IO caused by looking up meta data that should have been cached.

Re:Love ZFS still hoping for BTRFS

[fluffernutter]

From https://www.freebsd.org/doc/ha...

"Creating a ZFS storage pool (zpool) involves making a number of decisions that are relatively permanent because the structure of the pool cannot be changed after the pool has been created. The most important decision is what types of vdevs into which to group the physical disks. See the list of vdev types for details about the possible options. After the pool has been created, most vdev types do not allow additional disks to be added to the vdev. The exceptions are mirrors, which allow additional disks to be added to the vdev, and stripes, which can be upgraded to mirrors by attaching an additional disk to the vdev. Although additional vdevs can be added to expand a pool, the layout of the pool cannot be changed after pool creation. Instead, the data must be backed up and the pool destroyed and recreated."

It was too restrictive for me.

Re: Love ZFS still hoping for BTRFS

[Anonymous Coward]

You extend the pool by adding new vdevs, not by adding disks to existing vdevs. I really don't get how that's restrictive.

Re:Love ZFS still hoping for BTRFS

[dbIII]

No ZFS's thing is snapshots. Once you create a ZFS disk pool I could find no way to add a disk to it to make it bigger.

Add two disks or more :)
Don't think in disks, look up "vdev".

There are a few things to watch out for in linux ZFS for the moment until it catches up. The most important is to label your disks because unlike on solaris, bsd etc if they end up in a different hardware order they will drop out of the pool otherwise.

Re:Love ZFS still hoping for BTRFS

[rl117]

Extensible at *which level*?

If you're thinking in terms of filesystem size, and since you mention ext4 this appears to be the case, then this is a complete non-issue. ZFS *datasets* are the equivalent of filesystems, and these can grow and shrink freely; the only limit would be an optional maximum size you set on it, i.e. a quota. Otherwise it use whatever free space is available in the pool. This would be equivalent to growing and shrinking an LVM LV, but without any of the manual effort--to do the equivalent of adding or removing space, you simply adjust the quota. Dead simple, and totally safe; the same can not be said about shrinking--adjusting all the fs structures and then chopping the end off the block device with an LV resize is actually quite risky and dangerous in comparison--a mistake could trash all your data.

The other level would be the pool itself. This can be grown by addition of zvols (disk RAID sets, typically). You can't shrink the pool, that's really the only limitation. And it's not a particularly big problem, since the need to do this is rare in a production system. When all your data is in ZFS datasets, you don't fiddle with the system at this level--we're not doing manual partitioning or messing around with LV resizing any more. But that level no longer matters; all your data is simply contained in the pool, and managed in datasets, snapshots, as you see fit.

Re:Love ZFS still hoping for BTRFS

[Anonymous Coward]

BTRFS is dead in the water. Oracle pulled out and doesn't give a shit anymore since they acquired ZFS.
Seriously the only 2 viable options on linux are XFS and ZFS (since a good chunk of work was already done).
No one sane of mind would use BTRFS on a production machine.

Hi! Insane person here. I've used it in production for six years on dozens of systems. I've had 2 system* issues, both were systems running out of inodes on the root partition, which was not a btrfs flaw but a partitioning issue on the ext4 volume.

*User issues like blowing away DBs or trashing files also happened, and btrfs made those easy to recover from.

Re:Love ZFS still hoping for BTRFS

[rl117]

You have been extraordinarily lucky. No horrible dataloss. And you haven't hit the unblancing issues which make the filesystem read-only after an indeterminate period? Or are you doing a regular rebalance with associated performance loss and hoping for the best?

Re:Love ZFS still hoping for BTRFS

[Anonymous Coward]

You have been extraordinarily lucky. No horrible dataloss. And you haven't hit the unblancing issues which make the filesystem read-only after an indeterminate period? Or are you doing a regular rebalance with associated performance loss and hoping for the best?

Nope. I'm embarrassed that I don't even know about the balance option, though I'll check it out during weekend maintenance. I've only used scrub a few times a year for that matter.

I did have disks fill up from time to time, due to bad DB design and a chatty DB server. That would result in me dumping a compressed backup to another host/vm dropping the DB and recreating the db from the last few months of transactional data. Perhaps that bypassed the issues you hit? I'd also rebuild the VMs, creating fresh dd-ified disk images after 2-3 years in service for the "zombie" clients I'm not supposed to maintain but am also not approved to shutdown and delete :p The hosts are also power cycled at least once a year if you refer to a win95 38-day sort of thing.

Beyond that, I just made sure not to go over 90% on VM hosts running it. That's not even a btrfs thing, its just good policy. Mind you, I don't try to expand raids or LVMs or anything like that. Its all strictly SW raid/mdadm and old school partitioning.

Data loss indicates a bad design though, regardless of file system. Either no backups, or a fragile transactional system. I've had DBs get corrupt when the host (and UPS) lost power since we didn't budget for battery backup cached performance, but I could rebuild and reprocess any system in a few hours anyway because the transactional data was stored in multiple locations and hosts just in case. Think Netflix designed to fail redundancy vs trying to superman the server.

And this is all running on HP G7 era gear - at best. I still have a few 3rd party 1.5TB sata drives in some of them pushing 50k hours. They don't want to budget to replace it before it breaks, so when that happens, those zombies/archives just get lost forever...

Re:Jesus

[Anonymous Coward]

Okay, the comments on this thread are a shitshow. So far we have:

- JEWS DID 9/11

- prisoninmate loves ReiserFS

- Hillary will ban Linux

- FreeBSD >>>>>>>>>> Dumbuntu!

Welcome new user!

Re:Jesus

[zenlessyank]

Everyone is tired from the ARSTechnica website fiasco and so the only peeps on /. are trolls....cept me and you ;) and maybe danbob999

a better filesystem ideologically.

[Anonymous Coward]

That really depends on your ideology or whether you spot a difference between a projects stated ideology and the implemented policy. In this case its not dissimilar to the difference between the technical specification of bitterfs and how its been implemented.

distributions, not operating systems!

[Gravis Zero]

For those not in the known, ZFS on Linux is the official OpenZFS implementation for Linux, which promises to offer native ZFS filesystem support for any Linux distribution, currently supporting Arch Linux, Ubuntu, Fedora, Gentoo, Red Hat Enterprise Linux, CentOS, openSUSE, and now Debian

FTFY

Re:distributions, not operating systems!

[Anonymous Coward]

No. This is one of the many reasons the branding of Linux and Linux-based operating systems is so terribly bad. They are not called desktop systems, or operating systems, they are called Linux distributions, and consequently they are perceived as things for Linux people only, and people stick to Windows and Mac OS X.

Re:distributions, not operating systems!

[NIGGERpenisgoodPENIS]

No. This is one of the many reasons the branding of Linux and Linux-based operating systems is so terribly bad. They are not called desktop systems, or operating systems, they are called Linux distributions, and consequently they are perceived as things for Linux people only, and people stick to Windows and Mac OS X.

There certainly are Linux distributions that call themselves operating systems. PCLinuxOS is the first one I thought of. There are others.

But honestly - if something so trivial is a major deciding factor, then I'd rather that user just stick to Windows or Macs. I really enjoy finding a knowledgable community of fellow users when I discuss Linux. I don't share this need to "beat Microsoft" or whatever as though it's a big contest. Linux already has more than enough users to ensure active development. Because of that threshold being met, I care about the quality of users more than the quantity.

Re: Did you know?

[Anonymous Coward]

Have you ever considered the scenario where it gets downvoted not because it's some kind of secret truth being suppressed, but because it's both a stupid idea and off-topic?

Re:Jesus

[NIGGERpenisgoodPENIS]

Okay, the comments on this thread are a shitshow. So far we have:

- JEWS DID 9/11

- prisoninmate loves ReiserFS

- Hillary will ban Linux

- FreeBSD >>>>>>>>>> Dumbuntu!

Slashdot just isn't waht it used to be in the Rob Malda days. I knew it was gonna go downhill the moment Dice bought it.

For trolling at least GNAA actually *tried* and Mr. Alpha Papa Kilo was genuinely endearing sometimes. Spelling it phonetically because invoking his name is the easiest way to trigger the lameness filter - there can be no better testament to how much he is in the hearts and minds of Slashdot admin.

Oracle Software?

[Anonymous Coward]

Not on my computers...

Re:Oracle Software?

[Anonymous Coward]

Indeed, only a fool would use a file system hacked together by what is in the first place a web browser developer.

Why, or why not ZFS?

[lalleglad]

The inclusion of ZFS support into Linux has been discussed for so long I can't remember the first time anymore.

And what I still can't understand is, and please excuse me my ignorance:

1. What is it I can do with ZFS in Linux that is so important?
2. What is it I can't do without ZFS?

I am not saying that we shouldn't support ZFS, because I think we should eventually support anything and everything, but why all the fuss?

Re: Why, or why not ZFS?

[Anonymous Coward]

ZFS is a complete rethink of how a file system works. Think of it as mixing a file system with lvm. Managing data is just so much more convenient when you can group it into volumes that you can move around and handle without statically slicing up the hard drives or using thin provisioning. You make new file systems as you need them and they use as much space as they need. And that it also gurantees that the data you write is the same data that you get back out of it is also not bad. Just being able to do a scrub and knowing that all your data is still there is a great thing.

Re:Why, or why not ZFS?

[Tapewolf]

What is it I can do with ZFS in Linux that is so important?
What is it I can't do without ZFS?

It does a lot, but the features I'm interested in are the protection against bit-rot. Specifically, if you set up a mirrored pair of disks in a ZFS pool, it will checksum everything on both sides of the mirror.
When the array is checked (scrubbed), it verifies the checksums. If there is a mismatch because the data has glitched on the media, the checksum won't be valid on one disk, but it will be valid on the other disk so it can repair it. If there's a mismatch in a more conventional mirrored pair, the controller wouldn't really have a way to know which one is correct.

This capability is also in BTRFS, but much has been written about how BTRFS is still experimental. Also, last time I looked, BTRFS was only available for Linux - with ZFS it would be possible to migrate to FreeBSD if Linux does jump the shark.

The other thing is that the scrubbing process is done in the background. My main data pool is a pair of 4TB disks, which was EXT4 to begin with, then BTRFS and now ZFS. The system is a desktop which is powered down at night. Every 180 boots it would run FSCK, which took something like 2 hours to run on EXT4, during which the system was unusable. With BTRFS and ZFS, the scrubbing takes place while the pool is mounted. So yes, you can do this with BTRFS as well, but ZFS is the more proven option of the two.

Re:Why, or why not ZFS?

[Anonymous Coward]

Some other cool features not mentioned is what PC-BSD does with ZFS. When a new PC-BSD upgrade gets pushed out, it will first snapshot your boot volume, then mount it in a jail, then upgrade the OS in the jail. On next reboot, you load from the new boot volume, but you can go back to the old one in case something horrible borks the computer.

Another company that had a large world to build had issues managing all of the temp files and other crap that goes along with rebuilding a large system entirely from source. So they created a system that understood the make files, and would create new ZFS volumes pre-populated with the source files needed to build that sub-part of the system. The final output was written to a shared mount. Once that part of the build was complete, the jail and volume would get destroyed, leaving the system in pristine condition at all times. With a large world to build and a huge server to build it on, they were creating and destroying 11,000 ZFS volumes and BSD jails per second. As system admins, they loved not having to clean up after the build process.

Re:Why, or why not ZFS?

[Anonymous Coward]

NetBSD, OS X, and of course Illumos (son of OpenSolaris) distributions also support ZFS. It's ironically the most cross platform filesystem other than FAT32.

Re:Why, or why not ZFS?

[UnknownSoldier]

Here's an introduction to ZFS.
* http://wiki.illumos.org/download/attachments/1146951/zfs_last.pdf

At the time ZFS was written, nothing even came close to its features.

ZFS got famous for demos like this:
* ZFS is Smashing Baby

--
Robin Williams: Lived a hero, died a coward. :-(

Re:Why, or why not ZFS?

[UnknownSoldier]

Whoops, that first link should be:

* ZFS: The Last Word In File Systems

Re: Why, or why not ZFS?

[Anonymous Coward]

Where are the systemd haters? Shouldn't they be in here, yelling and screaming, because ZFS violates the Unix principle of separation? "It's one big monolithic blob!"

Re:Why, or why not ZFS?

[Anonymous Coward]

Good grief, as if the world owes you an explanation - google is your friend! You post is about as useful as people asking for phone numbers of businesses on facebook forums.

- Grumpy Australian

Re:Why, or why not ZFS?

[dbIII]

It's a very nice way of dealing with disk arrays with snapshotting and a pile of other features that are not so easy to get via other means. One feature is that it is trivially easy to copy entire filesystems to other machines and just as easy to add incremental updates. Another is not having to rely on having the same brand of RAID controller if you want to get the disks to work on different hardware, any SATA (or SAS for those disks) controller/s will do. A desktop PC with slots full of SATA cards of any brand could get you up and running when a file server dies.

Re:Why, or why not ZFS?

[dbIII]

Another thing - not having to wait for "fsck" to finish on large volumes when they come up again after a lot of uptime. File system checks are done on live filesystems, it's called "scubbing" on ZFS.

Re:Why, or why not ZFS?

[dbIII]

with ZFS it would be possible to migrate to FreeBSD if Linux does jump the shark

Less contraversally it's convenient to have it not only controller agnostic but also OS agnostic. I've connected up a pool created on linux to a FreeBSD box and it just works because it's designed to work in that situation.

Re: Why, or why not ZFS?

[rl117]

No. Because it doesn't violate it. And being a monolithic blob is the least of the criticisms which we could make about systemd, when there's an entire book's worth of bad design in there. ZFS was designed by competent and expert professionals, rather than unprofessional prima donnas, and it shows.

It's a fundamentally different design to traditional UNIX filesystems and disk management, but that doesn't automatically make it a monolithic blob. Is Linux LVM a monolithic blob? That's the level your question is at, as well as being flamebait.

Internally, ZFS is layered similarly to a Linux raid/lvm/filesystem setup. Here, you would have raw block devices managed by hardware or software RAID, with LVM using these devices as physical volumes. It would then provide logical volumes upon which you could create filesystems.

With ZFS, you would have block devices aggregated into "vdevs", which would be the equivalent of RAID0/1/5/6 RAID sets. These are the equivalent of LVM physical volumes. Next, you would use one or more vdevs to create a "zpool", which would be the equivalent of an LVM volume group. Finally, you would create datasets in the pool, which are the equivalent of a logical volume plus a filesystem, or a zvol which is the equivalent of a logical volume--a raw block device. So it's cleanly and logically layered. It's using plain block devices as the backing store as for any UNIX filesystem, but it's not creating intermediate block devices as LVM does--it's managing that internally.

The layering is pretty much the same--it's a well separated design. What's different is that ZFS has knowledge of all the layers and can use that to do things much more efficiently and much more robustly. For example, when doing a RAID rebuild ("resilver") it only needs to resync bits of the disk that actually have data on which can dramatically reduce the statistical likelihood of encountering an unrecoverable error. A dumb RAID setup doesn't know that, and will fail if it encounters an error during a full rebuild; ZFS will succeed if those errors were in areas weren't in use. And it can also be instructed to keep more than one copy of data for important stuff, which gives it an even higher chance of rebuilding in the face of corruption. There are a whole pile of other benefits as well, but as an admin the main benefit is that it's a dream to manage on a day to day basis, and you can even delegate management of sub-datasets to other users and groups, so they can snapshot their own data at will, send and recv data, create new datasets etc. The design is clean, well thought out and brings features which are completely missing from anything else.

Re:Why, or why not ZFS?

[Anonymous Coward]

ZFS works perfectly fine with OS X, with Linux YMMV. I use it for external hard drives where I need to use them between OS X and Linux boxes. Also use BTRFS on my Linux machines, going to roll them all to ext4, I'm fed up with going to BTRFS disks and finding for some reason the drive has become read-only. BTRFS is just too high maintenance to be usable, I don't want to care about the FS once it is formatted. ZFS on the other hand, we have 200TB of storage, I'd hate to know exactly how much RAM would be required, I'm guessing 200GB just for the FS?

GPL ? GNU/Linux ?

[ray-auch]

SFC says ZFS is a GPL violation and "“Almost There” is More Painful Than Proprietary" (see https://sfconservancy.org/blog... )

If so, surely we need to drop the "GNU" bit, since it is now merely a GNU system over another proprietary (or at least not FOSS, because it is a GPL violation) kernel? Or will rms continue to want crediting for distributions which violate (in his opinion) the very license he created?

Re:GPL ? GNU/Linux ?

[Anonymous Coward]

A few things: 1. ZFS is licensed under a FOSS license, CDDL. It happens to be incompatible with the GPL, but that's not a big deal. I mean, the GPLv3 is incompatible with GPLv2, both are still free licenses.

2. Debian is packaging a ZFS source package which will be compiled on the user's computer. this means a binary form of ZFS will not be distributed by Debian, so there is no license conflict as no binary ZFS module is distributed.

3. There is no legal basis for ZFS binary module to be considered a GPL violation. That's just BS being drummed up by the FSF and SFC. Legally speaking, kernel modules are not derivatives of the kernel.

Re:GPL ? GNU/Linux ?

[Anonymous Coward]

The SFC is not the be-all end-all legal authority on the GPL. The SFLC, which has been around much longer than the SFC, has a differing opinion on the issue. The only thing for sure is that a resolution will be adjudicated in the courts and not press releases.

Re:GPL ? GNU/Linux ?

[Anonymous Coward]

Who cares? FreeBSD is under a BSD license, which means you are really free to do what YOU want, not what some lunatic's idea of freedom is.

Re:GPL ? GNU/Linux ?

[jopsen]

2. Debian is packaging a ZFS source package which will be compiled on the user's computer. this means a binary form of ZFS will not be distributed by Debian, so there is no license conflict as no binary ZFS module is distributed.

But these days we distribute VMs/AMIs, etc all the time...

3. There is no legal basis for ZFS binary module to be considered a GPL violation. That's just BS being drummed up by the FSF and SFC. Legally speaking, kernel modules are not derivatives of the kernel.

Really? Compilation is not a violation, but we're talking about distribution right?
It's my understanding that the kernel has GPL exceptions for user-space code, but not kernel modules. This is the reasoning behind the horrible nVidia, AMD install nightmares, etc...

Re:GPL ? GNU/Linux ?

[Anonymous Coward]

Legally speaking your wrong. Canonical is legally in the wrong if they bundle a pre-built module. There is probably even an issue of contributory infringement with Debian distributing the sources. The SFC is not fighting this battle legally because it isn't worth it, not because they are wrong. This has nothing to do with the FSF either. In any event everybody agrees there are too many other bigger issues regardless of your opinion on this matter (whether you think it is or isn't an issue that is).

Re:GPL ? GNU/Linux ?

[Anonymous Coward]

Nobody is fighting this in the courts. Mark Shuttleworth freaked out about it because he apparently thought the SFC was going to do something legally speaking [by freaking out I don't mean publicly- it was internal communications that I'm aware of]. The SFC isn't taking anybody to court over this issue. I believe Mark was freaking out because he was contacted by the SFC about the issue after they made the decision to include a binary kernel module. Based on his communications with and reaction to the SFC chances are he is at this point trying to save his butt legally and save face on the issue. I think he realizes they were in the wrong legally speaking. His reaction makes me think Canonical will remove ZFS from a future edition once the commotion dies down or they will adapt the ZFS stuff at some future date to be less controversial with the SFC's position (ie distribute a package which builds from source instead). Essentially Canonical privately asked the SFC for time to resolve the issue.

* Note: I do not work for Canonical or the SFC nor do I have any obligation to keep anything private.

Re:GPL ? GNU/Linux ?

[Guy Smiley]

To be clear, SFC claims that including binary ZFS modules with the Linux kernel is a GPL violation. Not even SFC says that ZFS itself is a GPL violation.

Also, by no means is ZFS proprietary, even the OSF approved CDDL as an open-source license.

Re:GPL ? GNU/Linux ?

[tlhIngan]

SFC says ZFS is a GPL violation and "âoeAlmost Thereâ is More Painful Than Proprietary" (see https://sfconservancy.org/blog... )

If so, surely we need to drop the "GNU" bit, since it is now merely a GNU system over another proprietary (or at least not FOSS, because it is a GPL violation) kernel? Or will rms continue to want crediting for distributions which violate (in his opinion) the very license he created?

No, it's not a GPL violation. The real problem is ZFS is CDDL licensed, while Linux is GPLv2 licensed. Both are open and free software licenses, but both have incompatible restrictions - CDDL code cannot be included in GPL code and vice-versa.

The only solution is that NO distribution can include binary versions of ZFS on their Linux distributions because of the incompatibility. So you work around it because the license are only covering distribution - if the user doesn't distribute it, everything is A-OK. So a user can compile CDDL code into the kernel just fine, they just can't distribute the resulting binaries because it's a violation of both GPL and CDDL since you cannot satisfy both simultaneously.

If you're deploying internal VM images, you're technically not distributing so even that is OK, though it gets much trickier if you're using a cloud service. It also is a technical violation if you distribute the image to say, a contractor. In theory, you're fine as long as said contractor is using your equipment, but it gets very murky very quickly (i.e., it is distribution if you give the VM image containing both to a contractor to run on his personally owned computer).

But, given people trade movies and music freely, I'm guessing most people wouldn't have much of an issue with that either (violating open-source licenses is fine as it puts you under "all rights reserved" copyright, but distribution is technically copyright violation or piracy).

Re:GPL ? GNU/Linux ?

[ray-auch]

1. I know

2. Doesn't matter - "user does the link" or "user does the compile" is considered subterfuge by rms / FSF, there are endless historical pronouncements on this. See the discussions on gmp/RIPEM for a start (one summary here: http://tech-insider.org/linux/... ). Or any of the old usenet threads on "gpl and plugins".

3. Yes but if the FSF / rms consider it a violation, even if there is no legal basis, then we should drop the GNU/ from Debian etc. in deference to them.

Of course, it is possible that they want the GNU/ to remain in the name of something they consider a violation of their ideas and licence, but if so they can ask for it to be re-instated. It would be impolite for us to _assume_ that is what they want - it would be assuming that they are hypocrites....

Re:GPL ? GNU/Linux ?

[cas2000]

> Who cares? FreeBSD is under a BSD license, which means
> you are really free to do what YOU want,

unless you happen to get your copy from someone who doesn't want you, the user, to have any freedom. In that case, you're fucked - non-copyleft licenses like BSD do not protect YOUR freedom.

With non-copyleft licenses, ANYONE can place ANY restrictions they like on downstream users.

> not what some lunatic's idea of freedom is.

that "lunatic"'s idea of freedom is that ALL users should have the freedom to do whatever they want with the software, regardless of who/where they got the software from.

With copyleft licenses like the GPL, the ONLY restriction is that you can not place any further restrictions on downstream users. i.e. the only restriction exists solely to enforce freedom for everyone.

One of these is far more free than the other. Hint: it's not the one that allows arbitrary restrictions to be added.

Re:GPL ? GNU/Linux ?

[Anonymous Coward]

Oh, please, stop this disinformation once and for all.

BSD license lets you use some other license for YOUR CHANGES, but you MUST PROVIDE the BSD license with the derivative work you distribute. This means the end user has knowledge there is open source behind it, and can download it from the original source.

Only the changes you have done can be licensed under some other license (you have invested your time, as little as it may be, why wouldn't you use the license YOU want for YOUR WORK?).

Both BSD and GPL licenses have their uses, but don't tell GPL gives more freedom, because it is not true. It restricts freedom for downstream developers (they cannot use their own license for THEIR CHANGES), and it doesn't give any more freedom than BSD license to end users (they are still able to download the original source code with both licenses, even if the derivative work has been distributed with a restrictive license).

The way you say it, it seems you can place restrictions in the original BSD licensed code, but it is not true. The BSD licensed code will remain BSD licensed, the restrictions can only be applied to DERIVATIVE WORK.

Re:GPL ? GNU/Linux ?

[cas2000]

> Oh, please, stop this disinformation once and for all.

How about you stop with your bullshit?

This is NOT about re-licensing. I never said that the BSD-licensed code was somehow magically re-licensed, so you can stop pretending that I did.

However, anyone who distributes BSD-licensed binaries (whether modified or not) is under NO OBLIGATION WHATSOEVER to provide source code to anyone, ever. Not of their modified source and not even of the original unmodified source.

They're free to tell their users "fuck off and go find the source yourself. And good luck figuring out how to compile it, sucker!".

> Both BSD and GPL licenses have their uses, but don't tell GPL gives
> more freedom, because it is not true

It absolutely IS true. The GPL provides (and enforces) freedom for everyone, developers AND users. It also prevents anyone from restricting that freedom, AND it obliges re-distributors to provide the source code in the preferred (i.e. most usable) machine-readable form.

The BSD license does not in any way prevent anyone from restricting freedom, and creates no obligation to provide source code.

> they are still able to download the original source code with both
> licenses, even if the derivative work has been distributed with a
> restrictive license

This is disingenuous, at best.

Users aren't guaranteed a right to the source code of the software that they're actually running, that they have purchased as a software product or that is embedded in some hardware device they bought. With some fucking about and searching, they can probably get most or all of the source for the original code that the product they're using was based on, and that's all.

Now that may be exactly what the original code developers want, and it's absolutely their right to choose whatever license they want for their code. That still doesn't mean that the BSD license is as free as the GPL. It's not. It's inherently less free.

Re:Jesus

[inode_buddha]

It could be worse. I've seen threads dating to around 2001 where the GNAA got into a bot-posting war with the My Clean PC guy (anyone else remember those guys?). Slashdot was basically unusable for an entire weekend as every topic filled up with hundreds of copypasta... ... so, lately its actually been pretty quiet around here, IMHO.

Re:Jesus

[MrL0G1C]

Lol, I think the messenger just got shot!

Are License Issues Resolved? No? WTF Debian?

[Anonymous Coward]

Is this package building from source a kernel module? I believe the way Canonical is handling it is a GPL violation. Even if you don't distribute a pre-built module it is probably still technically contributory infringement (not that the Software Freedom Conservancy is going to make a big stink over it- there are just too many bigger fish to fry and severely insufficient resources to fix the bigger violator issues).

https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/

Re:This is great news!

[Anonymous Coward]

Well she met with some open source developers and said the exact opposite.

Re: This is great news!

[Anonymous Coward]

Both parent and GP are probably accurate. Most political candidates tell you what you want to hear.