Ubuntu 16.04 LTS To Have Official Support For ZFS File System (dustinkirkland.com)

LichtSpektren writes: Ubuntu developer Dustin Kirkland has posted on his blog that Canonical plans to officially support the ZFS file system for the next Ubuntu LTS release, 16.04 "Xenial Xerus." The file system, which originates in Solaris UNIX, is renowned for its feature set (Kirkland touts "snapshots, copy-on-write cloning, continuous integrity checking against data corruption, automatic repair, efficient data compression") and its stability. "You'll find zfs.ko automatically built and installed on your Ubuntu systems. No more DKMS-built modules!" N.B. ext4 will still be the default file system due to the unresolved licensing conflict between Linux's GPLv2 and ZFS's CDDL.

Comments

For home users, basically meaningless.

[Anonymous Coward]

All file systems are approximately the same for most day to day users. I would be interested in knowing which is fastest at read/writes.

Re: For home users, basically meaningless.

[Zeromous]

Large files brtfs or xfs.
For millions of small files...ext4

Re:For home users, basically meaningless.

[Anonymous Coward]

All file systems are approximately the same for most day to day users. I would be interested in knowing which is fastest at read/writes.

And that's meaningless without specifying the hardware you're doing the comparison on, your access pattern(s), file system layout, data distribution within the file system, and other factors.

Re:For home users, basically meaningless.

[Anonymous Coward]

I think you don't know what ZFS really is. It's a very different deal than etx4, ufs etc... It is the file system that made HW raid controllers obsolete. Even with a single disk setup you get a lot of features that you don't have on most of the other FS. It is a big deal just because of cheap snapshots, and data integrity checks.
And no, BTRFS is not even close... yet.

Re:For home users, basically meaningless.

[UnknownSoldier]

> I would be interested in knowing which is fastest at read/writes.

Ignoring the fact that this is a HIGHLY ambiguous question, i.e. you don't specify _which_ RAID setting, here are some benchmarks:

= 2010 =
http://www.zfsbuild.com/2010/0...

= 2013 =
ZFS On Linux 3.8 Kernel, ZOL 0.6.1
https://openbenchmarking.org/r...

= 2015 =
A PERFORMANCE COMPARISON OF ZFS AND BTRFS ON LINUX
* https://www.diva-portal.org/sm...

Re:For home users, basically meaningless.

[Curunir_wolf]

I think you don't know what ZFS really is. It's a very different deal than etx4, ufs etc... It is the file system that made HW raid controllers obsolete.

It also made just about any computer with less than 8 GB of RAM obsolete. It's also not very friendly with applications that need large chunks of RAM, like a database or large Java VM application - the ARC cache causes a lot of fragmentation and is often slow to release it when other applications need more.

Re:For home users, basically meaningless.

[Anonymous Coward]

All file systems are approximately the same for most day to day users

Not if they care at all about their data...

Re:For home users, basically meaningless.

[Aaden42]

On 64-bit hosts, the ARC cache is a non-issue. Java needs contiguous *virtual* memory space. Physical memory fragmentation isn't a problem w/ the MMU translating contiguous 64-bit address space to possibly non-contiguous physical pages. On 32-bit hosts, that gets dicey. On 64-bit, you've got plenty of room even w/ ARC.

That said, I'd love to see ARC & the native Linux disk cache functionality either merge or at least have ARC behave more like the normal caching mechanism (IE free up RAM more eagerly), but it's not actually caused me significant problems on 64-bit.

Re:For home users, basically meaningless.

[The-Ixian]

I used MythTV for years as a DVR and I tried a lot of different file systems.

The 2 that always worked the best were JFS and XFS for the sole reason that large file deletes took almost no time at all. Compared to several seconds or even minutes with other file systems.

Re:For home users, basically meaningless.

[MightyYar]

I had an incident where my photos folder suffered silent filesystem corruption. Fortunately, my backup tool (Unison) does enough file comparisons and did not brainlessly overwrite the undamaged images still in backup but instead flagged it as a conflict. It taught me a lesson about what is "good enough" for day-to-day users. Just like a lightning strike taught me about off-site backup for day-to-day users.

Re:For home users, basically meaningless.

[epine]

These benchmarks are sensitive to extremely subtle differences in how each file system interpret safety semantics, which unfortunately none of these "benchmark" utilities actually check.

By "subtle" I mean just a scattered handful of sunflower seeds, which may (or may notâ"don't look at the light!) attract the attention of the Black Swan of Extreme Face Melt.

One thing I read a while back explained how rigorous NFS semantics were pretty much guaranteed to cut your benchmark results in half, compared to how these semantics are traditionally implemented on just about any Linux system.

Is that bridge safe? The pragmatic answer is this: a million people have driven over it so far, and no-one has died yet.

To the kind of person who gets a secret thrill from "First post!" the logic of this probably seems impeccable.

Subject: First post!

I don't want a pickle,
I just want to r-i-i-ide my motor sickle.

cya
snookie—don't cry ... I love you so much!

Re:For home users, basically meaningless.

[ThomasSpaziani]

Not at all. ZFS with a nice GUI can be extremely useful for home users. The ability to custom tailor compression per folder, or snapshots for easy backup and quick retrieval of overwritten files. All that doesn't have to be enterprise only, it can have profoundly positive impact on general users day to day.

Re:For home users, basically meaningless.

[Anonymous Coward]

I think you don't know what ZFS really is. It's a very different deal than etx4, ufs etc... It is the file system that made HW raid controllers obsolete.

It also made just about any computer with less than 8 GB of RAM obsolete. It's also not very friendly with applications that need large chunks of RAM, like a database or large Java VM application - the ARC cache causes a lot of fragmentation and is often slow to release it when other applications need more.

Don't be afraid to cap the living crap out of the ZFS ARC. But check the results carefully - set it too small and your limit will be ignored.

Re: For home users, basically meaningless.

[Anonymous Coward]

I personally have read a lot of lost data horror stories with btrfs. Usually it isn't a small chunk of data, but a large partition that winds up with major problems. Because of this, I wouldn't want to use btrfs for anything production.

ZFS, on the other hand, has been tested in a ton of environments, and is what the big boys use when using Oracle/Solaris/SPARC.

Now, if RHEL and downstreams can feature ZFS, life will be nice.

Re:For home users, basically meaningless.

[fahrbot-bot]

I used MythTV for years as a DVR and I tried a lot of different file systems.

The 2 that always worked the best were JFS and XFS for the sole reason that large file deletes took almost no time at all. Compared to several seconds or even minutes with other file systems.

Yup. On my MythTV system, I use XFS on the filesystem hosting the video files and ext on the other filesystems.

Re: For home users, basically meaningless.

[Anonymous Coward]

I personally have read a lot of horror stories about btrfs who seem to be written by people who fears their dicks will fall off if it gains any traction. So there.

And not only that, I've been using it for years with out problems for years, NB without trying anything fancy like the raid support etc. So I guess my anecdote is better than yours. Be careful. ;)

Re: For home users, basically meaningless.

[Zeromous]

If you are using ZFS, you need to have the offline backup.

So many things can go wrong with ZFS due to failures beyond your control. You use ZFS so you don't have to restore, and keep an offline backup for when ZFS is fucked.

If you can't afford to offline your ZFS data, ZFS is not for you.

Re:For home users, basically meaningless.

[Anonymous Coward]

In my experience, large file deletions on XFS do take time if the files are fragmented. Fragmentation tends to only happen if you're keeping the partition 90 % full though...

I second the recommendation for JFS. It's a very CPU efficient file system. A shame nobody is using it.

Re: For home users, basically meaningless.

[Anonymous Coward]

Ummmm whoosh maybe? He's using it in a business setting and you are not, I think I'll listen to him and safely ignore you.

Re:For home users, basically meaningless.

[greenfruitsalad]

and none of that matters because Ubuntu's grub-efi doesn't even know how to boot from XFS, let alone from ZFS.

creating a separate /boot partition with ext4 defeats the purpose of ZFS and its most useful feature of boot environments. ZFS likes its disks whole, not partitioned.

Re:For home users, basically meaningless.

[UnknownSoldier]

I completely agree! Benchmarks only test performance and (usually) completely ignore correctness.

"It doesn't matter HOW fast you read/write if the data is WRONG" (The whole point of a FS (File System) is to guaranteed the data is valid!)

Benchmarks are not one-dimensional. We need to graph multiple axes:

* Correctness
* Throughput
* Latency
* IOPS
etc.

Where is the benchmark that demonstrates how well the FS handles "reboot -t now" right in the middle of writing a huge block of data??
Where is the benchmark that demonstrates how long it takes to fsck _that_ scenario?

--
StackOverflow sucks: Why can't you fix 1 character spelling mistakes??

Re:For home users, basically meaningless.

[lewiscr]

It also made just about any computer with less than 8 GB of RAM obsolete.

a) Pick the right tool for the job.
b) ZFS works fine without lots of RAM. Either cap the ARC, or disable it.

I plan to use ZFS for my personal NAS. I'll have 4TiB of storage (spinners) and 2GiB of RAM. It's mostly media storage, so ARC isn't terribly useful. And ZFS will auto-disable the ARC if the machine has less than 4TiB of RAM. Sure, it's not going to set any benchmarks records, but I don't need it to. Streaming media at the home scale isn't taxing for modern PCs.

It's also not very friendly with applications that need large chunks of RAM, like a database or large Java VM application

I love ZFS for my database servers. It plays very well with PostgreSQL, because in PG you can tell it how much RAM to use as a buffer AND estimate how much RAM the OS will use for cache. Just tell PG that the OS will do all the caching, and things are good. ZFS beat the crap out of my HW RAID card in the PG benchmarks, with the same amount of RAM, without adjusting the configs I mentioned.

And lets not forget the other great features it offers:

• It's beautiful for RAID1. mdadm is weak with partial failures. If a drive has bitrot, mdadm will tell you, but it can't tell you which drive is right. ZFS knows which one is right, and fixes it automatically.
• Auto expansion is available (disabled by default). I've been upgrading my personal NAS for 15 years, one part at a time. I have expanded the LVM+mdadm ext FS from 100GB -> 250GB -> 500GB -> 2TB. It's easier now that ext3 has online resize, but it's still a lot more work than ZFS.

I do wish ZFS could handle changing the layout on the fly, and shrinking volumes. It's corner case, but it would come in handy in some failure scenarios. Veritas Volume Manager was the only thing I've worked with that did this well, and that was hella expensive. (I consider any software that costs more than the machine that it runs on to be hella expensive.)

Re:For home users, basically meaningless.

[thegarbz]

All file systems are approximately the same for most day to day users.

Day to day users tolerate silent corruption of their data?

That's news to me.

Full disclosure: I'm a day to day user running ZFS because I've lost pieces of data to silent corruption before.

Re:For home users, basically meaningless.

[lewiscr]

XFS was designed to be a media filesystem, when SGI wrote it for Irix. It's a good fit.
I plan to use ZFS for my media storage, but there is one important consideration. ZFS does NOT like to be more than 80% full. If you're planning to fill the disks greater than 80%, stick with XFS. I'm not, so I'm going with ZFS. XFS still has issues in this scenario, but it's not as bad as ZFS.

Re:For home users, basically meaningless.

[Anonymous Coward]

In my experience, ZFS is kind of a dog on Linux. And on Solaris for that matter. Not tuned for performance.

We were trying to convert a Solaris x86 host to Linux and couldn't do it anyway since OpenSolaris is no more and ZFS has been updated a few times since then. You're basically stuck with obsolete ZFS which isn't much faster than NTFS (database application.)

Stick with XFS for stability or BTRFS for bleeding edge.

Re:For home users, basically meaningless.

[Curunir_wolf]

Interesting.

I plan to use ZFS for my personal NAS. I'll have 4TiB of storage (spinners) and 2GiB of RAM.

So are you using a Linux distro? I looked at doing something similar, but FreeNAS now needs 8 GB of RAM. I just want something like a home-built Synology. Small and efficient. I had pretty much ruled out using ZFS though.

I love ZFS for my database servers. It plays very well with PostgreSQL

I wasn't aware of that, but I don't use PostgreSQL for anything except one application, and it requires a LOT of resources. Most of my small stuff is SQLite and legacy MySQL. ZFS, I think, would kill MySQL.

It's beautiful for RAID1.

Seems like overkill for that, IMHO, but I've only had 1 failure on an mdadm mirror, and recovery was a snap, so I never looked for any other software solutions. I'm not sold on ZFS yet, but you've given me enough to want to take another look.

Re: For home users, basically meaningless.

[Anonymous Coward]

JFS is also pretty fast with large files and mature.

Re: For home users, basically meaningless.

[Anonymous Coward]

It doesn't *need* 8 GB RAM. I ran a 12 TB array on a server at home with 4 GB RAM. It was slow, but had uptimes if 6-8 months before I would install updates and reboot.

If you can afford it, you *should* give it more.

Re: For home users, basically meaningless.

[Curunir_wolf]

I guess I should have said "The FreeNAS Community page states under Minimum Hardware Requirements that at least 8 GB of RAM are required for current version of FreeNAS."

That better?

Re: For home users, basically meaningless.

[Anonymous Coward]

If you *put data on a disk*, you need to have the offline backup.

FTFY. The rest of your rant is completely meaningless.

Re:For home users, basically meaningless.

[fnj]

All file systems are approximately the same for most day to day users.

Possibly you could make that argument if all ZFS was, was a file system. That's not the case, though. ZFS is a fully integrated file system and logical volume manager, complete with built-in RAID facilities far more advanced than those available otherwise. Another vast advantage is the ability to create and destroy hierarchical file systems (not just directories) at any time during operation without interrupting operation. The creation is virtually instantaneous, and the destruction is asynchronous, so even "zfs destroy" of even an enormous sub file system returns to a prompt essentially immediately.

This is just scratching the surface of stuff you can't to in archaic ext4 or archaic xfs.

I would be interested in knowing which is fastest at read/writes.

Knock yourself out. Nothing could possibly interest me less than that particular metric; I am FAR more concerned with data protection and reliability; but we all have our own set of priorities.

Re: For home users, basically meaningless.

[fnj]

If you are using ZFS, you need to have the offline backup.

So many things can go wrong with ZFS due to failures beyond your control. You use ZFS so you don't have to restore, and keep an offline backup for when ZFS is fucked.

If you can't afford to offline your ZFS data, ZFS is not for you.

What the fuck did you just claim in that unintelligible post? Damned if I can figure out.

Re: For home users, basically meaningless.

[Anonymous Coward]

I'm running ZFS on a Fedora server with 2GB RAM and a 1TB pool (4 discs, RAID-Z), shared over NFS and samba. The box also runs several web services under Apache (Owncloud being the heftiest) backed by MariaDB, and postfix, IMAP, Bind, DHCPd and various other services. I've not had any issues due to low memory.

Re: For home users, basically meaningless.

[bestweasel]

That sentence is what put me off using it at home but maybe I should have another look. I took over support for a production system with ZFS not long after it came out and didn't really trust it but it never failed and had all those great features: easy to expand, constant fs checking, volumes, snapshots etc. Sun had some brilliant engineers.

Re:For home users, basically meaningless.

[fnj]

creating a separate /boot partition with ext4 defeats the purpose of ZFS

Utter bullshit. I have one ZFS server that is root-on-ZFS, and one with an etx4 root and boot drive. They are both equally useful and performant. Sure, you can do interesting things with root-on-ZFS, but after experiencing both, I am fairly well decided on balance I prefer not using it.

Re: For home users, basically meaningless.

[Zeromous]

It makes perfect sense when you consider how man people deploy zfs without understanding the implications

Of course you should have offline backup of all your data. And yet people archive dozens of TBs...deploy zfs for speed and error avoidance...but don't have the solution to back it all up. But yeah I'm just an idiot for stating the obvious that zfs Is not bulletproof.

Re:For home users, basically meaningless.

[Anonymous Coward]

ext4 should be just about as fast as XFS at deleting large files. Back when I ran a DVR, I was running ext3 and really noticed when deleting multi-gigabyte files due to ext3 not having extents support. That problem got addressed in ext4.

Re: For home users, basically meaningless.

[Billly Gates]

Home users use Windows so this does apply

Re: For home users, basically meaningless.

[Tough Love]

JFS is also pretty fast with large files and mature.

And unmaintained.

Re: For home users, basically meaningless.

[Tough Love]

The main drawback with zfs is, it does not have a repairing fsck and never will have one. The koolaid you are supposed to drink is that raid will fix any corruption, so if anything ever does go wrong, and that would include bugs, random memory bit flips, multiple disk errors (lightning storm anyone?) and any number of other hazards that defeat raid recovery, zfs is just screwed and won't even attempt to get back the data that is most probably still sitting there, mostly intact.

If you need snapshots and remote replication more than you need the comfort zone of being able to repair just about anything that goes wrong, then ZFS is for you, otherwise Ext4 is still the most robust general purpose filesystem around.

The other thing that really hasn't come out yet is, how does ZFS perform compared to Ext4? So far nobody has done proper head to head benchmarks on identical hardware and OS. Soon it should be easy. I'm guessing that ZFS comes in pretty solidly in the rear of the pack.

Re: For home users, basically meaningless.

[Anonymous Coward]

ZFS does not need a fsck utility because it cannot break like other filesystems. The only thing that can lead to data loss are hardware failures or bugs and in those cases even a fsck utility of other filesystems will not be able to recover the data. You understand that fsck repairs filesystem structures and addresses things that could go wrong in UFS, EXT3/4, etc. etc. None of these can happen in ZFS. There is nothing that a check utility will be able to recover.

Re: For home users, basically meaningless.

[Tough Love]

ZFS does not need a fsck utility because it cannot break like other filesystems.

Excellent sense of humour :)

Re: For home users, basically meaningless.

[Anonymous Coward]

Just like any filesystem. If it is fucked you have to restore from offline storage. There are no "so many things" that could go wrong. Disk failures and sofwtare bugs are the only two reasons that could cause data loss. No filesystem is bulletproofed against those.

Re: For home users, basically meaningless.

[Rutulian]

Um, what?

zfs scrub

Just because it isn't called fsck doesn't mean it doesn't have one.

Re: For home users, basically meaningless.

[fnj]

Again an un-proofread post. Sigh. But at least this time I can divine what you are saying. You are right that any data not backed up is at risk. Duh.

Re:For home users, basically meaningless.

[Rutulian]

I looked at doing something similar, but FreeNAS now needs 8 GB of RAM.

Meh. I played around with FreeNAS for a while but wasn't too impressed. It makes some things easy. If the preconfigured setup does everything you need, great, but if you need access to more configuration options/customization (like I did), it's a pita. Just grab a copy of zfsonlinux and role your own. It's really not much more complicated than any other filesystem+lvm setup.

Re: For home users, basically meaningless.

[Tough Love]

Um, what?

zfs scrub

Just because it isn't called fsck doesn't mean it doesn't have one.

Zfs scrub is just a raid repair, it does not understand the structure of the filesystem and therefore is incapable of repairing inconsistencies, or detecting any inconsistency that does not show up as a raid checksum failure. Zfs scrub is definitely not a repairing fsck, and it is beyond me why zfs boosters like to lie about that, or fool themselves.

Re: For home users, basically meaningless.

[Rutulian]

Zfs scrub is just a raid repair

Let's call it online block-level filesystem integrity checking and repair using a redundant copy if it is available. Simply saying it's "just a raid repair" understates what it actually does. With scrubbing, you can detect and fix silent data corruption, which is something you cannot do with traditional fsck.

it does not understand the structure of the filesystem and therefore is incapable of repairing inconsistencies

You will have to be more specific about what you mean. You are correct that it does not repair metadata inconsistencies, but that is because those are handled in a different way. The #1 thing fsck does for an ext filesystem is replay the journal upon a power-failure event. For zfs you don't need a fsck for this because the ZIL is replayed automatically every time the pool is activated. The #2 thing fsck allows you to do is manually repair inconsistencies that can't be restored by the journal. However, this is a mostly useless function as about the only thing you can do is delete orphaned inodes. You can get your filesystem mountable, but there is no way to verify what state the data is actually in afterward (did you just lose data, or did you merge some successful writes with some failed writes effectively corrupting your data?). With zfs, all writes are transactional. So if there is a metadata inconsistency that can't be repaired by replaying the ZIL, you just end up rolling back the whole transaction. You will lose new data, but you won't corrupt existing data.

Can you run into an obscure zfs bug that causes you to unrecoverably lose your entire pool? Yes, of course, which is why you need good backups in every case. But these aren't random inconsistency errors that one might expect to happen in any normal situation. If you were to corrupt the ext4 superblocks you would be just as screwed.

Re: For home users, basically meaningless.

[Tough Love]

Can you run into an obscure zfs bug that causes you to unrecoverably lose your entire pool? Yes, of course, which is why you need good backups in every case.

So obviously you understand that in some cases of corruption, Ext4 can recover useful data while with Zfs your only option is to restore from backup. Now try to explain to any Ext4 user who has successfully rescued data (and there are many, including me) why they should give up this safety net in the name of some psychobabble about how raid repair is just as good as fsck repair, if only you had proper backups. Oops.

Re: For home users, basically meaningless.

[Rutulian]

You cannot recover from bad ext4 superblocks with fsck, so how is this any different from the equally unlikely scenario of a zfs bug resulting in an unrecoverable zpool? You can recover data from ext4 using low-level tools, yes, but I have no reason to believe you can't also do this with zfs if you are comfortable with the underlying filesystem structure and know where to look. Most people just don't bother because restoring from backup is easier.

why they should give up this safety net in the name of some psychobabble about how raid repair is just as good as fsck repair,

You missed it. Scrubbing is better than fsck, for certain types of repairs, namely the ones that fsck doesn't do. But hey, do what you want, I don't care. I personally use both ext4 and zfs for different purposes. It's better to be pragmatic than ideological in my opinion.

You have yet to explain what safety net fsck actually provides that isn't accomplished by zfs in another way. I gave you my analysis, let's hear yours.

Re: For home users, basically meaningless.

[Tough Love]

The vast majority of linux users don't raid their root disk, nor do they make regular backups. For these users, the robust recovery capability of Ext4 is cherished. Note: we're talking about the majority of users, this isn't just theoretical. To address the needs/wants of these users, ZFS would need a repair facility beyond what it has, that ZFS will never have because of this weird wanking about how raid repair is all they will ever need. The bottom line is, using ZFS on workstations for most users is just nuts, and will continue to be nuts until ZFS devs get over their fear of proper fsck. Mind you, implementing a proper fsck on ZFS would be a huge project because internally, ZFS is a gigantic rambling mess. That is the real reason that ZFS doesn't have a repairing fsck, not because raid repair is just as good, but because implementing this is hard, and apparently beyond the skill and energy of current ZFS devs.

Re: For home users, basically meaningless.

[Rutulian]

You keep missing the question. What does fsck repair that is not handled internally by zfs transactional writes? Answer: nothing. Repairing metadata inconsistency with zfs, in the worst case scenario, amounts to rolling back to the last successful transaction. There is no (offline) fsck tool because there is literally nothing else you can do to fix metadata inconsistency errors that would be better than that. Scrubbing is a part of filesystem maintenance, but it is really a different tool for a different scenario. It's my fault for bringing it up, but it is unrelated to fsck for the uses you seem most concerned with.

The vast majority of linux users don't raid their root disk, nor do they make regular backups

While most of the benefits of zfs are lost if you don't RAID, you can still benefit from transactional writes. I wouldn't set it up that way personally, though, since the whole point of zfs is to maintain data integrity. If you don't make backups, well good luck with that. Forget the filesystem for a moment and just consider the increasing prevalence of SSDs. They can fail completely suddenly and without warning, and recovering the data is no simple matter. So what are you going to do without backups if that happens to you?

The bottom line is, using ZFS on workstations for most users is just nuts

I wouldn't use zfs on a workstation. That seems rather pointless to me. That is not what the article is suggesting either.

Re:For home users, basically meaningless.

[Anonymous Coward]

Day to day users would be the ones typically using windows, and tolerate all its flaws. Does Windows (in the desktop versions) do anything to prevent silent corruption of data?

Is it also news to you that you aren't a typical user?

Re: For home users, basically meaningless.

[Anonymous Coward]

ZFS will run fine on systems with 1GB of RAM. I am this ryao:

https://github.com/zfsonlinux/zfs/graphs/contributors

Feel free to ping me in IRC on freenode to confirm that. You can find me with the nick ryao in #zfsonlinux. You can confirm that the ryao on freenode is me from my gentoo developer mask on freenode, which is consistent with my guthub account.

I am posting "anonymously" because I do not have a slashdot account and gone so long without one that I do not see the point of changing that.

Re: For home users, basically meaningless.

[allo]

nope, small files are bad on ext2-4. Try to delete 100.000 small files in a a directory on ext4. Next try the same on xfs. The first needs like 30 seconds and more, the second works instantly.

Re: For home users, basically meaningless.

[allo]

His rant is correct.

For example the issue with not having ECC-RAM: https://forums.freenas.org/ind...

Or the checksumming thing.

Think of having a 20 GB VM-Image. One bit flips. In the unused space inside the VM's filesystem, but who knows this.
Next comes ZFS, detects a wrong checksum and deletes the whole image file (yeah, Host-FS is consistent again!).

Think of having a folder of JPEG files and a lot of bit flips. You would notice it only on very few, where it happens in the Header, the rest would have like one wrong pixel. But ZFS deletes them all.

Re:For home users, basically meaningless.

[greenfruitsalad]

once you experience boot environments properly integrated with grub, you'll never want to go back. 90% of stress from upgrades goes away. i have this on my storage servers (NexentaStor) and wish I could have it on ubuntu.

Re: For home users, basically meaningless.

[Zeromous]

Go fuck yourself, wanker. http://slashdot.org/comments.p...

BTRFS

[ssam]

I'll stick with BTRFS thanks. It gives me all those features, is GPL and has been trouble free for me on many TB of disks for several years.

Re:BTRFS

[fbobraga]

It's a promising fs, but is not very stable now: I've tried BTRFS in a netbook (with Arch): it corrupted a micro-SD disk so many times that I've gived up and used ext4 (from it: a never have considered to use BTRFS in production systems yet like I do with ZFS])

Re:BTRFS

[Anonymous Coward]

I'll stick with BTRFS thanks. It gives me all those features, is GPL and has been trouble free for me on many TB of disks for several years.

Encryption? Oh yeah:

Btrfs does not support native file encryption (yet), and there's nobody actively working on it. It could conceivably be added in the future.

"Nobody actively working on it" is a big problem with BTRFS.

BTRFS comes from Oracle - pre-Sun purchase. It was Oracle's answer to ZFS. And now Oracle owns ZFS and doesn't need a copy of the original. It's not quite abandonware, but the central impetus for it's creation and advancement is gone.

And most of all:

Is btrfs stable?

Short answer: Maybe.

Ouch. That's the official BTRFS wiki page.

Re:BTRFS

[lkcl]

If you pick your file system because its GPL, you're pretty retarded. And yes, retarded is the appropriate word here.

he's picking his file system so that he complies with Copyright Law. why would you have an issue with that? i also don't understand why a Corporation (Canonical) would encourage people to ignore Copyright Law.

Re:BTRFS

[Anonymous Coward]

As a die hard BTRFS user that chases kernel releases like a addict chases crack, I can't help but say that there are still some annoying issues out there.

While none have given me data loss, you'll get the occasional deadlock from a set of kthreads that do compression or a severe slowdown with next to no disk I/O and big WAITIO (usually get 16.xx Load in such cases on a quad core machine). For the slowdown case you'll get a speed drop from 150MB/s to 900~KB/s on spinning rust for a couple of minutes. Happens only after heavy use in the range of 2+TB written with forced compression.

ENOSPC? Not on my end. Trying to copy a file and running out of space results in WAITIO through the roof while BTRFS tries to find free space. I've had a job that stalled and thrashed the hard drive for 9 hours while it tried to recover space. At no point did it simply kill the transfer due to out of space, btrfs usage showed around 1GB of space left with plenty for metadata. It's at 1GB free for data extents and that's what kills the whole deal. You can't use that last 1GB, you'll just deadlock until some space is recovered by deleting files manually. Happens every time, just make sure to transfer something that is larger than the available free space and watch it suffer.

All this with Linux kernel 4.4.2. Looking at the various mailing lists with regular posts from people with obscure problems I've never encountered before, can't really say it's on par with ZFS stability. And ZFS On Linux is still missing a few things last I checked from the true ZFS implementation, but it's usable. Can't comment on ZOL long term stability, but I would feel comfortable enough using it instead of BTRFS for say a production server.

Re:BTRFS

[Bert64]

So given that Oracle creates btrfs as a competitor to zfs because the latter used a license incompatible with the linux kernel, and now they own zfs, why wouldnt they just gpl (or dual license) zfs and forget about btrfs?

Re:BTRFS

[DRJlaw]

he's picking his file system so that he complies with Copyright Law. why would you have an issue with that? i also don't understand why a Corporation (Canonical) would encourage people to ignore Copyright Law.

Identify the copyright violation:

"This problem is being worked around by providing the kernel facilities through a separate kernel module, a technical solution for a legal problem that is also being employed by vendors and distributors of proprietary hardware drivers."

The GPL does not autmatically apply to anything that touches the kernel. It only applies to derivative works of a GPLed work. If they write a GPLed wrapper that is a derivative of both the kernel and the ZFS sources and chose to dual license it, then there's no need for the ZFS sources to be GPL licensed -- merely the wrapper. No GPL-code-inspired modifications, no GPL-defined derivatie work and no GPL licensing requirement. (So sad.)

For a group which worships the copyright hack that the GPL represents, it's odd that so many become so blind and incensed by anyone who dares to come up with a couter-hack to overcome some of the license's more idiotic features (i.e., it's open source, but it's not pure, GPL-certified open source, so you can't use it with our stuff). The only case that comes close to supporting GPL proponents' borg-like interpretation of the term "derviate work" is the Oracle v. Google fiasco. If that's the company that you want to keep, don't expect sympathy from me.

Re:BTRFS

[UnknownSoldier]

Really? You're going to criticize the parent because they value freedom over pragmatism ??

Hint: He's using _Linux_ for _precisely_ that reason. The parent has _their_ reasons. Just because it doesn't agree with your ideology doesn't make it wrong _for them_, only you.

Re:BTRFS

[Anonymous Coward]

he's picking his file system so that he complies with Copyright Law. why would you have an issue with that? i also don't understand why a Corporation (Canonical) would encourage people to ignore Copyright Law.

Identify the copyright violation:

"This problem is being worked around by providing the kernel facilities through a separate kernel module, a technical solution for a legal problem that is also being employed by vendors and distributors of proprietary hardware drivers."

The GPL does not autmatically apply to anything that touches the kernel. It only applies to derivative works of a GPLed work. If they write a GPLed wrapper that is a derivative of both the kernel and the ZFS sources and chose to dual license it, then there's no need for the ZFS sources to be GPL licensed -- merely the wrapper. No GPL-code-inspired modifications, no GPL-defined derivatie work and no GPL licensing requirement. (So sad.)

For a group which worships the copyright hack that the GPL represents, it's odd that so many become so blind and incensed by anyone who dares to come up with a couter-hack to overcome some of the license's more idiotic features (i.e., it's open source, but it's not pure, GPL-certified open source, so you can't use it with our stuff). The only case that comes close to supporting GPL proponents' borg-like interpretation of the term "derviate work" is the Oracle v. Google fiasco. If that's the company that you want to keep, don't expect sympathy from me.

I had to write a module like that one.

The acronym for the module in our product was "bmrms". I forget what the "official" meaning was, but it really meant Bite Me RMS

Re:BTRFS

[UnknownSoldier]

The parent is probably referring to the fact that CDDL is NOT compatible with the GPL.

https://lists.debian.org/debia...

Unfortunately Sun then developed the CDDL[1] and JÃrg Schilling
released parts of recent versions of cdrtools under this license.
The CDDL is incompatible with the GPL. The FSF itself says that this
is the case as do people who helped draft the CDDL. One current and
one former Sun employee visited the annual Debian conference in Mexico
in 2006. Danese Cooper clearly stated there that the CDDL was
intentionally modelled on the MPL in order to make it GPL-
incompatible. For everyone who wants to hear this first-hand, we have
video from that talk available at [2].

You can read the FSF position about the CDDL at [3]. The thread behind
[4] contains statements on the issue made by Debian people; for more
context also see the other mails in that thread.
In short - the CDDL has extra restrictions, which the GPL does not
allow. JÃrg has a different opinion about this and has repeatedly
stated that the CDDL is not incompatible, interpreting a facial
expression in the above-mentioned video, calling us liars and generally
appearing unwilling to consider our concerns (he never replied to the
parts where we explained why it is incompatible). As he has basically
ignored what we have said, we have no choice but to fork. While the CDDL
*may* be a free license, we never questioned if it is free or not, as it
is not our place to decide this as the Debian cdrtools
maintainers. However, having been approved by OSI doesn't mean it's ok
for any usage, as JÃrg unfortunately seems to assume. There are several
OSI-approved licenses that are GPL-incompatible and CDDL is one of
them. That is and always was our point.

[1] http://www.opensource.org/lice...
[2] http://meetings-archive.debian...
[3] http://www.gnu.org/licenses/li...
[4] http://lists.debian.org/debian...

Re:BTRFS

[ssam]

GPL gives the best chance that in the long term there will be multi vendor support. So in 20 years time I'll still be able to read my data, and no one can hold it hostage with crazy licence fees. Sure other open source licences are pretty close, but if the main sponsor behind a project goes closed, then it can sometimes take the community with it. Who knows if in the next 20 years Oracle will do a SCO and try suing anyone who uses their tech in a way that does not generate profit for them.

Re:BTRFS

[Anonymous Coward]

So given that Oracle creates btrfs as a competitor to zfs because the latter used a license incompatible with the linux kernel, and now they own zfs, why wouldnt they just gpl (or dual license) zfs and forget about btrfs?

One
Raging
Asshole
Called
Larry
Ellison?

Re:BTRFS

[Aaden42]

ZFS on Linux doesn't support native encryption yet either. ZFS on Solaris does, but that code was added after OpenSolaris was killed and has never been released under a clearly CDDL license. (It *has* been leaked, but not with clear CDDL license assignment, thus nobody in their right mind has touched it.)

You *can* easily do ZFS on LUKS-based encryption on Linux. It works great, but it's a very different thing with a different feature set than native ZFS encryption. Native ZFS crypto allows encrypting individual zfs filesystems with different user-owned keys. It's possible to boot the host with only part of the zpool accessible with the encrypted parts only accessible to the owning (mortal) users when they provide key material. ZFS on LUKS is full disk encryption with no way to import the pool at all without keys. It's all-or-nothing access to the encrypted zpool. Once it's unlocked and imported, anyone on the system can access anything on the zpool. On the other hand, ZFS native crypto leaves filesystem metadata (filenames, paths, sizes, mtimes, etc.) in the clear, even without the key. ZFS on LUKS encrypts everything.

I've been using ZFS on LUKS for about six years now. It's a stable and reliable approach, but it's not fair to say ZFS "supports" encryption where BTRFS doesn't. You can BTR your LUKS just as easily I'd think (never tried though).

Re:BTRFS

[ssam]

I am using BTRFS on luks on my laptop. Even during a motherboard failure that cause repeated hard poweroffs I did not loose any data (and thanks to data checksumming I know that there is no corruption lurking in the files). BTRFS has developers at Facebook, Fujitsu, SUSE, IBM and still gets patches from people at Oracle. Seems a fairly healthy project to me.

Re:BTRFS

[Aaden42]

Oracle considers ZFS a competitive advantage. It's their answer to NetApp's WAFL. Not sure the reasoning behind creating btrfs (other than possibly just merger schedules resulting in them owning both), but it's very likely they consider the GPL/CDDL incompatibility and resulting copyright FUD/trolling to be a feature. Having an in-tree ZFS module on Linux isn't something Oracle wants to see.

Re:BTRFS

[wolrahnaes]

The GPL does not autmatically apply to anything that touches the kernel. It only applies to derivative works of a GPLed work. If they write a GPLed wrapper that is a derivative of both the kernel and the ZFS sources and chose to dual license it, then there's no need for the ZFS sources to be GPL licensed -- merely the wrapper. No GPL-code-inspired modifications, no GPL-defined derivatie work and no GPL licensing requirement. (So sad.)

There's actually a lawsuit going on right now about this very tactic. https://sfconservancy.org/copy... (article source is funding the suit, so apply grains of salt as appropriate)

IANAL, but the position I've always heard (and seemingly the one this lawsuit is taking) is that the "GPL shim" is only legitimate in cases where the proprietary side it's interfacing with is the same on other platforms. In that case instead of just being an obvious attempt to run around copyleft it becomes a mere adapter to a vendor's standard interface. Supposedly this is how the nVidia driver has worked for a long time now, the binary blob is the same on all supported operating systems and only the shim that adapts it to each kernel differs. VMware's attempt on the other hand appears to be pretty much the opposite side of the spectrum, with heavy integration with one specific kernel under the guise of a "shim".

Personally I think that's a legitimate workaround, since in the end most drivers exist to connect the kernel with some proprietary black-box hardware over an interface that's standard to the hardware but may or may not be documented. That the public standard interface is implemented in software rather than hardware doesn't seem like it should be meaningful to me.

I guess if that suit runs to completion we'll at least see some line drawn in the sand legally which obviously wouldn't directly apply to anywhere not under German law but would probably influence future cases.

Re:BTRFS

[Anonymous Coward]

The GPL does not autmatically apply to anything that touches the kernel. It only applies to derivative works of a GPLed work. If they write a GPLed wrapper that is a derivative of both the kernel and the ZFS sources and chose to dual license it, then there's no need for the ZFS sources to be GPL licensed -- merely the wrapper. No GPL-code-inspired modifications, no GPL-defined derivatie work and no GPL licensing requirement. (So sad.)

There's actually a lawsuit going on right now about this very tactic. https://sfconservancy.org/copy... (article source is funding the suit, so apply grains of salt as appropriate)

IANAL, but the position I've always heard (and seemingly the one this lawsuit is taking) is that the "GPL shim" is only legitimate in cases where the proprietary side it's interfacing with is the same on other platforms. In that case instead of just being an obvious attempt to run around copyleft it becomes a mere adapter to a vendor's standard interface. Supposedly this is how the nVidia driver has worked for a long time now, the binary blob is the same on all supported operating systems and only the shim that adapts it to each kernel differs. VMware's attempt on the other hand appears to be pretty much the opposite side of the spectrum, with heavy integration with one specific kernel under the guise of a "shim".

Personally I think that's a legitimate workaround, since in the end most drivers exist to connect the kernel with some proprietary black-box hardware over an interface that's standard to the hardware but may or may not be documented. That the public standard interface is implemented in software rather than hardware doesn't seem like it should be meaningful to me.

I guess if that suit runs to completion we'll at least see some line drawn in the sand legally which obviously wouldn't directly apply to anywhere not under German law but would probably influence future cases.

And people wonder why the GPL is considered poison...

Re:BTRFS

[Anonymous Coward]

The GPL does not autmatically apply to anything that touches the kernel. It only applies to derivative works of a GPLed work. If they write a GPLed wrapper that is a derivative of both the kernel and the ZFS sources and chose to dual license it, then there's no need for the ZFS sources to be GPL licensed -- merely the wrapper. No GPL-code-inspired modifications, no GPL-defined derivatie work and no GPL licensing requirement. (So sad.)

There's actually a lawsuit going on right now about this very tactic. https://sfconservancy.org/copy... (article source is funding the suit, so apply grains of salt as appropriate)

One major difference, which may or may not make a difference, is that ZFS started out on not-Linux and came to Linux very late in the game. While the VMware folks started working on Linux from the very beginning.

So I think it would be hard to argue that ZFS was "dervied" in any way from GPL code.

Re:BTRFS

[Anonymous Coward]

> corrupted

You sure?

I've had BTRFS crash numerous times (when I turn encryption on), but in every case, it politely hung **before** it actually corrupted any data.

I used btrfs with compression turned on to deal with some very update-heavy large files (100+GB VM disk images and 1GB database files), that started extremely compressible (mostly zeros), but became less so as the VM and database was used more.

A few times, btrfs "crashed" when applications were trying to access the file; and syslog suggested that btrfs "ate my data". However after a reboot I was able to `read()` the files just fine; I just wasn't able to `seek(...); ...; write(...);` to them ---- so a really easy workaround was `cp badfile badfile.new; mv badfile.new badfile` and everything worked again.

Turned off btrfs compression, and haven't had a problem since.

***TL/DR: sometimes it looks like btrfs ate your data when it really didn't***

(if anyone's curious, the two different crashes I had, that each recovered with the above workaround are below)

Dec 10 12:28:46 i5 kernel: [1399240.917183] RIP: 0010:[] [] btrfs_set_item_key_safe+0x161/0x170 [btrfs]
Dec 10 12:28:46 i5 kernel: [1399240.917215] RSP: 0018:ffff88000dea5b70 EFLAGS: 00010286
Dec 10 12:28:46 i5 kernel: [1399240.917228] RAX: 00000000ffffffff RBX: 0000000000000001 RCX: 000000064c050000
Dec 10 12:28:46 i5 kernel: [1399240.917245] RDX: 00000000ffffffff RSI: ffff88000dea5c76 RDI: ffff88000dea5b8f
Dec 10 12:28:46 i5 kernel: [1399240.917262] RBP: ffff88000dea5bc8 R08: 0000000000000001 R09: ffff88000dea5b90
Dec 10 12:28:46 i5 kernel: [1399240.917278] R10: 000000064c051000 R11: 00000000ffffffff R12: ffff88000dea5b7e
Dec 10 12:28:46 i5 kernel: [1399240.917295] R13: ffff880290a6f2d0 R14: ffff88000dea5c76 R15: ffff8801405632c0
Dec 10 12:28:46 i5 kernel: [1399240.917311] FS: 0000000000000000(0000) GS:ffff88041f200000(0000) knlGS:0000000000000000
Dec 10 12:28:46 i5 kernel: [1399240.917330] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Dec 10 12:28:46 i5 kernel: [1399240.917344] CR2: 00000000bd3bb008 CR3: 0000000001c0e000 CR4: 00000000001427f0
Dec 10 12:28:46 i5 kernel: [1399240.917360] Stack:
Dec 10 12:28:46 i5 kernel: [1399240.917366] ffff880405124800 6aa6ffffa0282989 006c000000000046 a6000000064c04f0
Dec 10 12:28:46 i5 kernel: [1399240.917385] 6c0000000000466a 000000064c04f000 ffff8801405632c0 000000064c050000
Dec 10 12:28:46 i5 kernel: [1399240.917404] 0000000000000000 0000000000000f96 ffff880290a6f2d0 ffff88000dea5cc0
Dec 10 12:28:46 i5 kernel: [1399240.917423] Call Trace:
Dec 10 12:28:46 i5 kernel: [1399240.917438] [] __btrfs_drop_extents+0x421/0xad0 [btrfs]
Dec 10 12:28:46 i5 kernel: [1399240.917461] [] btrfs_drop_extents+0x60/0x90 [btrfs]
Dec 10 12:28:46 i5 kernel: [1399240.917482] [] insert_reserved_file_extent.constprop.53+0x6c/0x290 [btrfs]
Dec 10 12:28:46 i5 kernel: [1399240.917509] [] btrfs_finish_ordered_io+0x2e5/0x570 [btrfs]
Dec 10 12:28:46 i5 kernel: [1399240.917531] [] finish_ordered_fn+0x15/0x20 [btrfs]
Dec 10 12:28:46 i5 kernel: [1399240.917564] [] worker_loop+0x15a/0x5c0 [btrfs]
Dec 10 12:28:46 i5 kernel: [1399240.917597] [] ? btrfs_queue_worker+0x310/0x31

Re:BTRFS

[armanox]

That would only apply to future versions of ZFS though. Hence why we have projects like OpenIndiana that are based off of the now closed Solaris source from when it was all CDDL (from SXCE pre-Solaris 11)

Re:BTRFS

[Anonymous Coward]

It's only poisonous to retards and freetards who want something for nothing. I think we're better off without them anyway so good riddance to them and you.

Re:BTRFS

[Anonymous Coward]

Bitterfs has its chance, but that was sometime ago. I'm sure that red hat derivatives will claim it has parity with filesystems that came before and since but.....

Re:BTRFS

[Kjella]

The GPL does not autmatically apply to anything that touches the kernel. It only applies to derivative works of a GPLed work. If they write a GPLed wrapper that is a derivative of both the kernel and the ZFS sources and chose to dual license it, then there's no need for the ZFS sources to be GPL licensed -- merely the wrapper. No GPL-code-inspired modifications, no GPL-defined derivatie work and no GPL licensing requirement. (So sad.)

That's not how copyright works. If you have say a piece of code licensed for non-commercial use you can't just write a wrapper and say my commercial use application talks to a wrapper, the wrapper talks to your code so the terms don't apply. Instead it relies on a sleight of hand where the user is creating the illegal derivate through assembling bits that were acquired legally using a prepared script. Just like you can acquire a bunch of legal chemicals, start a meth lab and end up with an illegal product.

Re:BTRFS

[thegarbz]

he's picking his file system so that he complies with Copyright Law. why would you have an issue with that? i also don't understand why a Corporation (Canonical) would encourage people to ignore Copyright Law.

Because the copyright law isn't clear on the specifics, hence the premise of not using ZFS for of GPL is silly, and Canonical is not doing anything illegal.
The way I understand it:

Can CDDL code and GPL co-exist in a binary blob? No
Can CDDL code run as a separate binary to the GPL blob and talk to it (aka module)? Yes
Is Canonical shipping a Linux Kernel with CDDL code in it? No
Is it legal to use ZFS on Linux providing it is it's own module / in user mode / all tools to manage it are separate from GPL code? Yes

There's no issue here.

Re:BTRFS

[lewiscr]

Oracle doesn't give away anything they can sell.

ZFS v28 was the last version that was open source, by Sun.
Oracle is still developing newer versions of ZFS, but they are closed source.
I believe ZFS is available in Oracle Linux, but I haven't verified that. I'm not sure how they get around the licensing issues.

Re:BTRFS

[lewiscr]

That sounds better than ZFS. If you actually manage to fill one up 100%, you're (probably) screwed. Due to it's Copy On Write implementation, deleting a file requires free space.
If you have some snapshots, you can drop those to free up some space. If you don't have snapshots to drop, your only option to recover is to enlarge the volume. You can either add another RAID extent (which you can't ever remove), or replace all of the disks with larger disks and expand.

Re:BTRFS

[DRJlaw]

That's not how copyright works.

Please, tell this practicing IP attorney how copyright works...

If you have say a piece of code licensed for non-commercial use

The GPL says nothing about commercial versus non-commercial use.

you can't just write a wrapper and say my commercial use application talks to a wrapper,
you can't just write a wrapper and say my commercial use application talks to a wrapper the wrapper talks to your code so the terms don't apply.

See my previous sentence. You're also talking about a user restriction, not an obligation to license derivative works under a particular license if they are distributed to others.

Instead it relies on a sleight of hand where the user is creating the illegal derivate through assembling bits that were acquired legally using a prepared script.

But the GPLv1-v3 licenses do not restrict the creation of derivative works at all. Those licenses restrict how you can distribute derivative works. Unless the user distributes the product of the prepared script, there's no violation.

That is hardly slight of hand -- now you're arguing that RMS wanted to control how individual users could use code on their own machines. Which is hilarious, because that's excatly opposite his stated goal.

If if you argue that the script is a derivative work, the ZFS code is a separate work developed apart from the kernel and the script. The GPL cannot touch the ZFS code and, by its own terms, does not control how the user privately uses the GPL code, whether in combination with other GPLed code, CDDL-licensed code, or Nvidia's super-proprietary and non-free driver code.

Just like you can acquire a bunch of legal chemicals, start a meth lab and end up with an illegal product.

Bad analogy is bad. Film at 11.

Re:BTRFS

[Anonymous Coward]

You can probably go back through the transaction groups and drop those to free up space, although this won't be a simple or clean operation.

You can absolutely prevent this from happening by enforcing a quota.

A more relevant concern is trying to make large zvols that consume more than 50% of available space: not possible due to built-in safeguards to ensure a snapshot is always possible. Annoying to deal with if you are working with iscsi exports.

Re: BTRFS

[Anonymous Coward]

What are you talking about?
Oracle is just one small contributor. Facebook, SUSE, Fujitsu and others are working actively on lots of stuff. Inline deduplication is on its way in, bugfixes happen all the time, is that the profile of abandonware? Nah.

Yes it is still stabilizing. It is still under development, hence the "maybe".

Re:BTRFS

[fph il quozientatore]

Btrfs is the default filesystem on my phone, and it's worked just fine up to now, for me and for most other users. The only issue I had is that it needs rebalancing every now and then, and the cron job is set up to do it only if the phone is connected to a charger when it starts (but that is an issue with the phone developers, not with btrfs).

Re:BTRFS

[thegarbz]

Troll? Really? I guess facts are hard to digest for some people with mod points.

For containers

[DrYak]

More precisely, the blog bost is about using ZFS' copy-on-write (CoW) capabilities in the context of linux containers.
(thin virtualized machines. The guest share the same kernel as the host, but the userspace is separated and compartmentalized using the kernel's cgroup feature.
Similar to BSD Jails and Solaris containers.
Think like a chroot, except extented to all the other concepts beside file system).

The fast and easy snapshoting that come with CoW filesystems like ZFS (or BTRFS for that matters) makes it very easy to spin new virtualized containers simply by snapshoting the subtree holding the empty template, while wasting only minimal resource (only the differences are stored as the two copies diverge over time).

Re:For containers

[BitZtream]

For containers (at least on FreeBSD) its far better to have one base install of the OS like you like it, and just use nullfs mounts to overlay that with a writable directory for each container.

Where ZFS's snapshots and clones will kick total ass is KVM virtual machines.

In either situation, at least on FBSD, you can allow the guest container/vm to manage their own ZFS, stays part of your larger pool and works as expected, but the children can create snapshots, clone, and filesystems in their little portion on the tree, and you can limit them with quotas.

Re:For containers

[KiloByte]

Except that for running containers you really want BTRFS rather than ZFS, as having many containers means you use your memory. ZFS shines on a file server where it can use all memory for itself and there's no need to actually use the page for a running process -- EXT4, BTRFS and any other well-behaved filesystem will share a page with processes that mmap it.

Re:For containers

[inhuman_4]

Indeed. I do this on my company's internal VM server with LXC+BTRFS and it is amazing. Once we get one system setup we can snapshot it and make many copies. Even better is for working with old versions. Since we keep a copy of each old image, if something comes up its easy to spin up a clone of an old version and reproduce the customers issue.

Re:For containers

[Anonymous Coward]

To clarify this, the main advantage of (read-only) nullfs is patching/upgrading. COW doesn't help there, but with nullfs because they are all pointing at the same files, upgrading one upgrade them all.

First post!

[fbobraga]

* from a ZFS running Windows system (i know... I'm obligatorily using Windows on my work) :P

Re:First post!

[BitZtream]

Liar.

Show me this ZFS on windows.

Re:First post!

[fbobraga]

It was a joke :-)

Re:First post!

[fbobraga]

I was joking :-)

Re:First post!

[darkain]

Export a ZFS volume via iSCSI, mount it on a remote machine and install Windows on it. The ZFS machine can now snapshot and clone the Windows install at will!

16.04 will be really exciting LTS

[Parker Lewis]

12.04 and 14.04 were kind of previous versions with updated programs, nice polished and updated drivers. But 16.04 will have exciting new stuff: privacy enabled by default, ZFS, new software centre, first LTS with systemd (yeap, mind that, I like it!) and kernel 4.

Re:16.04 will be really exciting LTS

[fbobraga]

I can't wait: for the first time I'm considering to use Ubuntu servers, instead of Debian/CentOS ones, on my work ^^

Re:16.04 will be really exciting LTS

[Parker Lewis]

LTS series is perfect for this. We use in our production servers (previously we're using CentOS). No regret!

Re:16.04 will be really exciting LTS

[Anonymous Coward]

first LTS with systemd

Thanks for making it easy for me not to upgrade.

Re:16.04 will be really exciting LTS

[Anonymous Coward]

Another new software centre? Why do they never spend the time to do proper requirements gathering and then only rebuild the thing once?

Re:16.04 will be really exciting LTS

[Anonymous Coward]

LTS series is perfect for this. We use in our production servers (previously we're using CentOS). No regret!

Yep, with an LTS your bugs and security holes will not be fixed for five whole years!

Whatever you do on Ubuntu stay far away from the universe and multiverse components. It's so much bit rot there by now the place is almost useless on anything that you want security updates for. Main (and maybe restricted) is the only one for a server, you just have to deal with the much limited number of packages.

Re:16.04 will be really exciting LTS

[kthreadd]

They didn't build it, they just switched to GNOME Software.

Re:16.04 will be really exciting LTS

[fnj]

I can't wait: for the first time I'm considering to use Ubuntu servers, instead of Debian/CentOS ones, on my work ^^

Me too. Even FreeBSD.

Re:16.04 will be really exciting LTS

[Anonymous Coward]

Wait for the first point release. This LTS looks explosive.

Re:16.04 will be really exciting LTS

[Anonymous Coward]

And it has a version of gcc that supports c++14.

(Yeah, yeah, you can use a PPA to get a modern version of gcc, but 99.x% won't do that.)

"Xenophobic Xenu"

[Anonymous Coward]

"Xenial Xerus"

To be followed by "Xenophobic Xenu".

Like a train wreck in reverse

[BaronM]

Every time I see news about ZFS and Linux, it's a little bit less of a mess. Eventually, I expect that all of the major distributions will go this route and sidestep the licensing issue by providing distro-supported modules that are installed by user request, sort of like the way that Nvidia drivers are provided.

Re:Like a train wreck in reverse

[castionsosa]

I'm just hoping this becomes officially supported in RedHat and downstreams (CentOS, Oracle UBL, SuSE, etc.) Backups will be easy, as I can just do a ZFS send, pipe it to a zbackup repository on a NAS, call it done.

RAID? For one pool, get a bunch of large, slow drives, add a pair of SSDs (as they will be hit heavily) for ZIL/L2ARC, and use RAID-Z2 for everything else. This way, if bit rot is encountered, ZFS can not just find it, but fix it. This way, random I/O is handled effectively, but most data can just migrate to the relatively slow spinning platters for safekeeping.

Re:Like a train wreck in reverse

[Anonymous Coward]

I expect that all of the major distributions will go this route and sidestep the licensing issue by providing distro-supported modules that are installed by user request, sort of like the way that Nvidia drivers are provided.

Will that approach allow allow a distro to use ZFS as the default for the root partition?

In that case, it seems that ZFS would need to be available at a very early stage during installation. What about supporting unattended installation? Will that be handicapped by the requirement that the user must first make a specific request to load ZFS, prior to formatting the root partition as ZFS?

Re:Like a train wreck in reverse

[BaronM]

I don't see why it couldn't be used for /, as long as the appropriate module is present in initrd (or initramfs, etc.) As for unattended/scripted, the options you put in the script are still choices. As I understand it, the one thing you can't do is compile ZFS directly in to the kernel to avoid the GPL/CDDL incompatibility.

Re:Like a train wreck in reverse

[fnj]

Every time I see news about ZFS and Linux, it's a little bit less of a mess.

I've been using ZFS on Linux for years, and the only thing that ever came close to being a mess was the horseshit called DKMS. Under CentOS6 (and I suspect any other linux), it absolutely insisted on building a mess of something it called "weak-modules" when I updated the kernel. These are nothing more than a mess of symlinks to the old module, and they kept breaking my system. I never found a workable way to prevent their creation, and fixing the damage always called for very careful ripping out of the links, and teasing DKMS into creating a proper new module in their place.

Also, rebuilding ZFS from source (using either DKMS or not) takes forever.

If Ubuntu will now do my rebuilding for me, and get rid of the DKMS abortion, that has my full attention. But I've never had the slightest problem from any part of actually running ZFS itself on linux.

XFS

[Anonymous Coward]

Uber alles. Default in CentOs 7. Why ZFS? It's not like anyone uses woobuntu in serious environments.

Re:XFS

[Anonymous Coward]

Just because CentOS has "Enterprise" in the name doesn't make it more "serious". I've got experience with both (and others) in "serious" environments and was very happy when I finally could dump the antiquated CentOS / Scientific Linux / RHEL for - you guessed it - "woobuntu" :-)

Re:XFS

[BitZtream]

I use both.

And for the reference, theres a REALLY REALLY good chance that you've had phone calls that have traversed one of the ubuntu machines that aren't for serious environments.

The fact that you make such a retarded statement shows how utterly clueless you are about Linux. You're one of those guys who thinks distros are different from each other ... Just because Linux distros can't decide on where they want to put a given set of files and they all must use their own package manager that does the same thing as all the others ... doesn't actually make them different.

It makes them different to people who don't know how to be an admin, but can add users on their preferred OS can as such call themselves an admin.

Re:XFS

[aethelrick]

Last time I looked... Ubuntu was the most popular Linux on AWS, not sure about OpenStack, but I got the impression it was doing well there as well. I think it's a bit harsh to say "It's not like anyone uses woobuntu in serious environments."

Re:XFS

[LichtSpektren]

Uber alles. Default in CentOs 7. Why ZFS? It's not like anyone uses woobuntu in serious environments.

Ubuntu is the biggest OS for enterprise cloud deployments in the world.

Re:XFS

[Anonymous Coward]

So sorry to hurt your feelings. To be more specific, Ubuntu LTS releases have ridiculously short support cycles. Compare this to June 30, 2024 for CentOS 7. Hence me wondering why anyone would use it in a serious environment.

Re:And systemd

[Anonymous Coward]

And I can't for them to find out that basically everything you've written is a bunch of lies, regurgitated by a sad little troll who has probably never used Linux in their life but has just jumped on the latest /. bandwagon 'for the lulz'.

Where's The Lie?

[Anonymous Coward]

Where's the lie?

Does systemd not replace the system log with a binary file that is unusable by every application that reads or writes to the system log?

Does systemd not break the system administration tool chain?

Does systemd not consume and discard STDERR making troubleshooting and debugging a masochist's delight?

Up until 14.04LTS everything dumps into /var/log/syslog, a standard text file. Beginning with 16.04LTS and thanks to systemd that is replaced by a binary file that is virtually inaccessible by everything else. No more logwatch, splunk is a pain in the ass, fail2ban recently got systemd support (cheers!), logger no worky...

But wait, there's more. All your network interfaces are gone. Good old eth0 eth1 etht1.3 all gone. Now you have to go searching and finding enp2s0 or god knows what that systemd decided to rename the network interface to because naming it eth0 is broken? eth0 needs to be deprecated? These are simply a few of the first things that will generate knee jerk reactions. The problems go so much further and so much deeper.

Where's the lie? I'm not talking about fanbois running Fedora in their mom's basement. I'm talking about the admins of hundreds of thousands of servers crying out in pain. Shit is going to get real. The systemd debacle is about to turn into an all out riot and that ain't no lie!

Re: Where's The Lie?

[Anonymous Coward]

Um I know you're probably trolling, but your an idiot. Why don't you spend some time and get to know the tools that systemd introduces. You may find you like it. You can still configure it to log to the places you're used to.

And the nic name changes have nothing to do with systemd. It's like your raging against cars for replacing horses

Re: Where's The Lie?

[Anonymous Coward]

your an idiot.

lol

Re:Where's The Lie?

[Eunuchswear]

Where's the lie?

Does systemd not replace the system log with a binary file that is unusable by every application that reads or writes to the system log?

No.

Does systemd not break the system administration tool chain?

No.

Does systemd not consume and discard STDERR making troubleshooting and debugging a masochist's delight?

No

Up until 14.04LTS everything dumps into /var/log/syslog, a standard text file. Beginning with 16.04LTS and thanks to systemd that is replaced by a binary file that is virtually inaccessible by everything else.

Run rsyslogd.

Won't bother with your boring crap about eth0. All my network interfaces have real names, which works with udev just like it used to.

Re:Where's The Lie?

[Anonymous Coward]

Except eth0 etc all disappeared long before systemd was even created.

Re:Where's The Lie?

[Cramer]

While true, many (all?) distros let udev screw with interface names, most of them leave the name eth# and remember which was which by MAC. Most important here is how simply an admin could turn that crap off. systemD doesn't use "eth" anymore, and the formerly simple methods of stopping this (lock a file, remove a script, etc.) are no longer that simple. Is it the end of the world, no. But it is still a needless pain in the ass.

RAM?

[AntEater]

ZFS is seriously cool in many ways, but you pay for that with some pretty significant RAM requirements for a file system driver. If I remember correctly, you need about 8GB of RAM to really make use of ZFS. I think it's great that they're including it with the distribution, but it wouldn't make sense to have this as the default file system. At least not until the average system out there is running with 16GB of RAM.

Re:RAM?

[UnknownSoldier]

> ZFS is seriously cool in many ways,

Indeed. Does anyone have an updated version of this ZFS vs BTRFS table cheat/sheat?

http://www.seedsofgenius.net/s...

> but you pay for that with some pretty significant RAM requirements for a file system driver.
> If I remember correctly, you need about 8GB of RAM to really make use of ZFS.

Yeah ZFS could be considered "bloated" but you get so many SWEET benefits.

Personally, I'd recommend having at least 8 GB of RAM solely just for ZFS RAIDZ1/RAIDZ2, leaving the other 8+ GB for apps.

Re:RAM?

[guruevi]

Which Server isn't running 16GB at least these days? Even a cheap dedicated server comes with it default. And ZFS doesn't actually require all that much RAM, it does better (read caching etc) with it and it requires it a lot for dedupe but a 'standard' file system can easily go with 1 or 2GB of RAM).

Re:RAM?

[Anonymous Coward]

You only need a lot of RAM if you're using the de-duplication features, otherwise you can limit the size of the ARC (adaptive replacement cache) to 256-512MB. Obviously this impacts performance somewhat but I've never seen it degrade below spindle speed e.g. if your disks average 200MB/s, ZFS will do ~200MB/s even without the ARC. You can also very easily add SSD caches (L2ARC) which will mitigate this.
 
For what it's worth, I've never found the deduplication to be worth it. It's very CPU and RAM intensive and for the resource cost you might as well just buy a few more drives.

Re:RAM?

[Anonymous Coward]

You do not remember correctly. ZFS does not require much RAM at all. I've been running ZFS on my Raspberry Pi 2 computer for about a year now, it has 1GB of RAM and handles multiple TB of data without any problem. If your computer has 2GB of RAM or more then you will never run into a problem or performance issue running ZFS.

ZFS _can_ use up to half of the available RAM for cache. So if you have 16GB it will try to cache up to 8GB of data in RAM, until the OS needs that space for something else. Then ZFS frees up its internal cache and gives the RAM back to the OS. This is how cache works for other file systems, it's just that ZFS handled cache internally instead of getting the OS to manage cache for it.

Re:RAM?

[Aaden42]

Do not, repeat DO NOT ENABLE DE-DUPE unless you have gargantuan amounts of RAM.

Rule of thumb is 5GB of RAM per 1TB of ZFS data: http://constantin.glez.de/blog...

If you ever enable dedupe on a pool, it's on forever. You can't actually turn off the extra RAM requirements since there *could* be de-duped blocks, and ZFS must check for those on every pool import. On a system with insufficient RAM, it's possible to end up with a pool that can take hours or days to import with no indication that it's actually still importing and not just dead.

Unless you have truly epic levels of duplication, it'll be cheaper to buy more disk to hold the extra copies than to buy enough RAM. (Also keeping in mind that with snapshots & copy-on-write clones, you essentially get dedupe of those blocks for "free" without enabling pool-wide dedupe.)

Re:RAM?

[Anonymous Coward]

I've been using ZFS on a FreeBSD server for many years without problems with only 2GB RAM. It's only a simple mirrored pool though, with not very many datasets.

Re:RAM?

[Anonymous Coward]

Also don't enable dedup if you have media with a nontrivial seek time. It's tolerable on flash (but you do lots of extra I/O on write) but the deduplication table (DDT) tends to develop a random layout with respect to device LBAs, and the DDT needs to be consulted on each write to a dataset/zvol with dedup enabled, and it also needs to be scanned *first* during scrubs and resilvers. DDTs with millions of entries can require hundreds of thousands of random I/Os, which means hundreds of thousands of seeks. At 10-30 ms/seek, you will have a bad time if you ever need to replace a disk in your pool, or scrub regularly.

Additionally, you have to update the DDT when you remove duplicates. When you remove a file from a deduplicated dataset: DDT consult. If DDT is not in memory, that means random I/O. When you remove a snapshot filled with data entered into the DDT: DDT consults for each record (128k, typically; sometimes smaller). Worse, asynchronous destruction of snapshots and datasets across a reboot boundary must be finished before the pool becomes available during the import process. And at the reboot, your ARC is empty and your L2ARC is unavailable before import, so each removed record is much more likely to result in a disk seek.

On SSDs, not so bad. On rotating media, deduplication can result in operational disasters -- I have personally seen pools take a WEEK to import after an unexpected restart during a "zfs destroy -R foo/bar" where bar has dedup=on.

Re:RAM?

[Anonymous Coward]

At my work (running a VM hosting infrastructure), we charge almost nothing for CPU and a lot for RAM.

Re:RAM?

[Anonymous Coward]

Just to address some of the ZFS FUD.

You are probably quoting the often misused "8 GB ram +1gb/TB of storage". .this is for DEDUP.

I have a backup server with 54TB of disk and 16GB ram. True, more then 8GB but if you look at he memory usage it is mostly allocated to the ARC and if i wanted i can shrink this via a tuneable.

Some systems seem to have issues with low ram ZFS implementations (freenas comes to mind) but no one ever determined exactly why. On the flip side, they have a statement about not running freenas+zfs on less then 8gb to protect people who use it from having issues.

Lastly, as others have pointed out, where does one get a "server" with less then 16GB ram?

Re:RAM?

[fbobraga]

Which Server isn't running 16GB at least these days?

All, except one webserver and two databese servers (which has 48GiB each) - besides it, there's another 20+ servers with 2GiB-8GiB of RAM here...)

Re:RAM?

[Anonymous Coward]

Just pray nothing bad happens. The truly insidious thing with ZFS is that it's very easy to fool oneself that it's working well with little RAM, until something goes wrong. And then when things *do* go wrong, you're in real trouble.

Re:RAM?

[kthreadd]

Lastly, as others have pointed out, where does one get a "server" with less then 16GB ram?

I have an old Sun Ultra 2 server still running. I think it's close to 20 years old now. It has 512 MB of RAM, runs ZFS on Solaris 10. It's doing just fine.

Re:RAM?

[Solandri]

Deduplication is the RAM hog (it's also a performance killer). I run a ZFS file server (FreeNAS) on just 5 GB of RAM with deduplication off, despite FreeNAS recommending 8 GB. I haven't had any problems (in fact the logs rarely show it going above 2-3 GB of usage - only when I copy a huge number of files to it at once does it go above that).

Deduplication sounds cool and all, but if you don't have a heavy need for it (e.g. you're running 20 identical virtual machines with their files stored on ZFS), just save yourself a lot of headaches and turn it off. Buying additional hard drive space is cheaper than buying extra RAM and processor power to deal with deduplication.

Re:RAM?

[thegarbz]

If I remember correctly, you need about 8GB of RAM to really make use of ZFS.

No. ZFS has performance advantages with more RAM available to ARC cache, and file de-duplication is incredibly RAM intensive, but both are configurable / optional features.

You can still get all the wonderful features of a modern CoW filesystem with data integrity checks with even a tiny amount of RAM. The minimum ZFS needs is 1GB almost to itself to run well, and that should be achievable on even the most basic of systems (16GB of ECC RAM is like $100, and if you're not willing to spend even 1/3rd of that then you have no right to complain about performance of an advanced filesystem).

Re:RAM?

[dk20]

Unable to login from work so i posted anon..

I have an old SUN X4500 running solaris 11.3, 16GB ram and incredibly the system doesn't have issues with 3TB drives.

Too little, too late...

[__aaclcg7560]

I used to use Ubuntu for my file server. Since the desktop motherboard didn't have a built-in video, I used an old Nvidia video card to configure the installation. Every time Ubuntu did an automatic upgrade of the video driver, it hosed the installation and I would have reinstall. I switched over to FreeNAS five years ago and haven't looked back. I've rebuilt my server box last year to meet the beefier hardware requirements for ZFS. Bad things will have if you run ZFS on less than adequate hardware.

Re:Too little, too late...

[LichtSpektren]

I used the wrong tool for the job, therefore it sucks.

Re:Too little, too late...

[Anonymous Coward]

A better analogy... I put a Ford oil filter on my Chevy pickup truck. The filter blew off causing all the oil to drain out and the engine seized. Chevy sucks.

Re:Too little, too late...

[ssam]

Why do you need the closed nvidia driver on a server? Nouveau should be fine or even just the vesa driver. (I could say why do you even need a video card on a server, but I guess some folk prefer that to using ssh or a serial connection from a laptop)

Re:Too little, too late...

[Anonymous Coward]

almost logged in to say this. Thank you for saving me time.

Re:Too little, too late...

[Anonymous Coward]

Linux is supposed to be good with older hardware compatibility. It doesn't matter how he was using the computer, if he was using it as a standard desktop the update process would have still hosed the installation. Upgrades shouldn't do that.

Re:Too little, too late...

[__aaclcg7560]

Nouveau should be fine or even just the vesa driver.

I don't know if that was an option five to ten years ago.

I could say why do you even need a video card on a server, but I guess some folk prefer that to using ssh or a serial connection from a laptop

If the installation got hosed from the video update, SSH wasn't going to work. The only way to diagnose and reinstall Ubuntu was with the video plug. Keep in mind that this was an old PC underneath my desk at home.

Re:Too little, too late...

[__aaclcg7560]

I used the wrong tool for the job, therefore it sucks.

Please explain what "tool" I should use to turn an old PC with a Nvidia video card into a file server underneath my desk at home?

From 1997 to 2010, I've used Linux and SAMBA. Every now and then, the installation got hosed. In the early days, it was compiling the kernel the wrong way. With Ubuntu, it was the video drive upgrade for the Nvidia card and happened so frequently that I had the installation steps memorized.

From 2010, I've used FreeNAS. A USB stick would go bad and hosed the installation from time to time. Formatting a new USB stick, installing FreeNAS and copying over the backup config file took five minutes.

Re:Too little, too late...

[LichtSpektren]

I used the wrong tool for the job, therefore it sucks.

Please explain what "tool" I should use to turn an old PC with a Nvidia video card into a file server underneath my desk at home?

From 1997 to 2010, I've used Linux and SAMBA. Every now and then, the installation got hosed. In the early days, it was compiling the kernel the wrong way. With Ubuntu, it was the video drive upgrade for the Nvidia card and happened so frequently that I had the installation steps memorized.

From 2010, I've used FreeNAS. A USB stick would go bad and hosed the installation from time to time. Formatting a new USB stick, installing FreeNAS and copying over the backup config file took five minutes.

Well, your original post said you didn't have a video card, so at that point you should've used Ubuntu Server or Debian or something else that doesn't require X.org. However, you used an old video card so you could get a GUI going. Fine. But after the second or third time a driver update broke it, you should've at that point began to decline the driver updates--you said it was a file server, right? You don't need the latest gfx drivers for that.

Re:Too little, too late...

[__aaclcg7560]

But after the second or third time a driver update broke it, you should've at that point began to decline the driver updates

I did. Ubuntu still saw that I had Nvidia video installed in the system and managed to hose the installation anyway. I don't know if this process got any better since 2010, but this was a PITA at the time I was using it.

you said it was a file server, right? You don't need the latest gfx drivers for that.

This was my only Linux box at the time. Recruiters told me I needed to Linux GUI experience on my resume. The problem with that was I prefer minimalist windows managers to open terminal and web browser windows, what recruiters really wanted was Red Hat GUI experience as specified on their requirement checklist, and all my work experience to date was command line Linux. After I switched over to FreeNAS in 2010, I stopped worrying about Linux and/or Red Hat GUI experience. The only Linux flavors I mess around with these days are Linux From Scratch at home and Fedora at work.

Re:Too little, too late...

[Anonymous Coward]

A USB stick would go bad and hosed the installation from time to time. Formatting a new USB stick, installing FreeNAS and copying over the backup config file took five minutes.

Yeah, having to reinstall the entire system is such a major "improvement" over having to reinstall a video driver (which is automatized to begin with). Oh the places the cognitive dissonance of some peeps takes them when trashing linux.

Re:Too little, too late...

[Anonymous Coward]

Every time Ubuntu did an automatic upgrade of the video driver, it hosed the installation and I would have reinstall.

Cool story bro.

Re:Too little, too late...

[__aaclcg7560]

Yeah, having to reinstall the entire system is such a major "improvement" over having to reinstall a video driver (which is automatized to begin with).

Redoing FreeNAS takes five minutes. Redoing Ubuntu and Samba took three hours (180 minutes). Think about that. Five minutes versus 180 minutes. Which one is faster?

Oh the places the cognitive dissonance of some peeps takes them when trashing linux.

Most people expect an automated driver update not to hose the entire operating system.

Re:Too little, too late...

[Anonymous Coward]

If the installation got hosed from the video update, SSH wasn't going to work. The only way to diagnose and reinstall Ubuntu was with the video plug. Keep in mind that this was an old PC underneath my desk at home.

You literally have no idea what you are talking about.

Linux isn't windows. SSH isn't tied to your GUI experience.

Re:Too little, too late...

[__aaclcg7560]

You literally have no idea what you are talking about.

I think your reading comprehension skills are failing.

Linux isn't windows. SSH isn't tied to your GUI experience.

If the video update hoses the installation (i.e., it doesn't boot), SSH won't be running. As for Windows, I never had a video update that hoses the installation.

Lies

[dlenmn]

It's not quite abandonware, but the central impetus for it's creation and advancement is gone.

I wasn't planning to comment on this thread, but this is too big a lie to let stand -- unless by "not quite abaondonware" you mean "has absolutely nothing in common with abandonware besides being a type of software". Oracle was never the sole developer, and now that Oracle has lost interest, the developers just moved to other companies and kept doing the same thing. Its raison d'etre remains to provide an advanced filesystem that's easily integrated with linux, which for better or worse means being licensed under the GPL or something compatible.

As for encryption, yeah that would be nice to have, but it's not like zfs has all the features btrfs has. I'll take btrfs's online balancing (ability to add and remove drives at will) over built in encryption, but I realize that's a personal choice.

Finally, let's actually quote the FAQ correct only stability:

Short answer: Maybe.

Long answer: Nobody is going to magically stick a label on the btrfs code and say "yes, this is now stable and bug-free". Different people have different concepts of stability: a home user who wants to keep their ripped CDs on it will have a different requirement for stability than a large financial institution running their trading system on it. If you are concerned about stability in commercial production use, you should test btrfs on a testbed system under production workloads to see if it will do what you want of it. In any case, you should join the mailing list (and hang out in IRC) and read through problem reports and follow them to their conclusion to give yourself a good idea of the types of issues that come up, and the degree to which they can be dealt with. Whatever you do, we recommend keeping good, tested, off-system (and off-site) backups.

Pragmatic answer: (2012-12-19) Many of the developers and testers run btrfs as their primary filesystem for day-to-day usage, or with various forms of real data. With reliable hardware and up-to-date kernels, we see very few unrecoverable problems showing up. As always, keep backups, test them, and be prepared to use them.

For all practical purposes, btrfs is stable. Everything they say in the long answer basically applies to linux in general (unless you have a support contract with Red Hat or the likes).

Re:Lies

[Bengie]

Open ZFS doesn't have encryption because it's low priority since all of the OSes have proper bootable transparent full-disk encryption.

Facts! Where Are Yours?

[Anonymous Coward]

And out comes the ad hominem! The standard arguement in favor of systemd is; 'everyone else are idiots and every way else is stupid'. Why? 'Because systemd said so!'

Why don't you spend some time and get to know the tools that systemd introduces.

For the same reason that you, and everyone else, don't spend the time to learn about the convoluted set of tools that I have developed for my specific needs. They're unneeded, irrelevant, and uninteresting wastes of time.

You may find you like it.

What I've found is that I dislike it intensely. I dislike impediments to system administration, broken workflows and having to relearn even the most basic and rudimentary things that were not broken in the first place. Using your logic, I should probably just learn to use Windows. Actually...

You can still configure it to log to the places you're used to.

I can recompile my system form source too, but neither one is a viable option from a usability standpoint.

And the nic name changes have nothing to do with systemd.

Really? Well then where do they come from? systemd seems to have decided and implemented it.

But, you keep right on with the ad hominem name calling. Don't answer the legitimate questioning of the systemd authority. Ignore the citations and provide not even a vaguely cogent argument. 'Everyone is an idiot and systemd is the only way forward.'

Re:Facts! Where Are Yours?

[armanox]

The NIC name change predates systemd by quite a bit and is unrelated - that change happened in udev IIRC.

Re:And systemd

[Anonymous Coward]

Diff AC here.

I use OS X, so I don't know much about the state of Linux these days.

But whenever systemd comes up here, I see people against it pointing out flaws that sound pretty serious, and making cogent arguments as to why systemd is problematic.

Anything that might interfere with logging, for instance, is something I'd consider to be a very serious problem.

Then we have the people who either support systemd, or are, for whatever reason, against those people who have experienced problems with systemd.

Instead of presenting a reasonable argument, these pro-systemd comments typically use insults ("sad little troll", "your (sic) an idiot") and false accusations ("everything you've written is a bunch of lies"), and contribute nothing of substance to the conversation.

As an outsider looking in, I consistently see the the anti-systemd side presenting solid techical arguments, while the pro-systemd side consistently presents childish name-calling.

This makes me think that something is wrong with the pro-systemd crowd.

When I weigh the evidence, I have to put far more trust in the anti-systemd comments presenting real technical arguments, and no trust at all into the pro-systemd comments filled with insults, vitriol, and sometimes even gibberish.

Hard links

[fluffernutter]

As far as I know, ZFS is the only file system that can deal with duplicating hard links appropriately. Say you have a backup pool that works with hard links, and you want a clone of that pool, very difficult with anything else.

Re:Hard links

[Anonymous Coward]

I think, but I am not sure, but HAMMERfs does this as well.

Re:And systemd

[fbobraga]

Posting AC? Why?

As well as...

[Anonymous Coward]

...Mir and Wayland and Half-Life 3. I'll believe it when I see it as an installable option.

Clean updates

[DrYak]

To clarify this, the main advantage of (read-only) nullfs is patching/upgrading. COW doesn't help there, but with nullfs because they are all pointing at the same files, upgrading one upgrade them all.

This would work for very small updates (e.g.: where a library .so file is replaced).
- before the update, the container was pulling a library from the template
- after the update, the container is still pulling from the same location, and now the template provides the updated version.

For large scale upgrade, that touch many files, including files - like config files - that got changed in the container and thus reside in the nullfs' overlay directory.
These files won't get automatically updated. You'd be upgating the original copy in the template, but the container would still be pulling their own local copies from the overlay.

The only solution would be to either:
- do an rsync from the updated template to the container you want to update (and hope you won't override some container-specific modification in the process)
- or do a separate update within the container (and that is going to work as expected under most circumstances).
and then subsequently run a de-dup.

(Which, in case of overlays, would be removing any file from the overlay directories that is actually exactly the same as one in the updated template).
(And wich is simply using the de-dup tool of the CoW filesystem)

Beside, the whole point of container with CoW, is that they are very thin and very light, and thus really easy to quickly spin on the flight.
(think systemd's nspwan).
Thus, depending on the circumstances, you might be better off just respining a new container.
(Specially since systemd's is supposed to be stateless and completely transparent to spin).
And in that circumstance, there's a slight performance benefits of using snapshots instead of overlays:
- no overhead of the overlay mecanism (e.g.: everything stays in the BTRFS layer)
- CoW works at the extent level (only the sub part of giant file that diverged gets writen) wheseas most overlays I know of work at the file level (a whole new copy of the file gets written).

ext4/ext3/ext2

[Anonymous Coward]

I'm still waiting for the ext4 driver to stop grinding my ext2 and ext3 partitions every 5 seconds while it tries to apply ext4-style journaling to them. The problem goes away when I use a kernel compiled without any ext4 support whatsoever.

Did You See The Fine Link?

[Anonymous Coward]

Did you see the fine link to a citation in the previous post? There's not need for your flawed recollection. It's right there in the link!

UDEV offered the user an option to rename the NIC. systemd offers no options and demands that applications be rewritten to conform to their methodology. This is a way of thinking that I actually don't have an issue with. My real issue is that every major Linux distribution bought into it for no valid reason.

Re:And systemd

[LichtSpektren]

It's also going to have systemd throughout.

I can't wait to hear the howling when people upgrade and suddenly they can't even write to or read logs in any way. I'm dieing to see the reactions when their told that they have to rewrite every script and application that they've used fro the last few decades because some moron decide to freshen the init system.

Cheers!

FUD like this did a lot of damage to the free-software community a few years ago, when systemd was first being deployed by the major distros. Nowadays nobody believes it anymore.

I use Ubuntu MATE 15.10 with systemd, and I'm perfectly capable of reading my syslogs. My shell scripts all worked perfectly when I upgraded from 14.10. Never had any boot problems.

Re:And systemd

[LichtSpektren]

Diff AC here.

When I weigh the evidence, I have to put far more trust in the anti-systemd comments presenting real technical arguments, and no trust at all into the pro-systemd comments filled with insults, vitriol, and sometimes even gibberish.

I'm not exactly sure where you're getting this from. The "real technical arguments" are all lies (you can use syslogd with systemd, you can configure systemd to not use binary logs at all, there's still STDERR). Saying so is not "insults, vitriol," or "gibberish." Maybe if you actually tried it, you'd see so.

N.B. I'm not "pro-systemd" by any measure, it's just another set of tools I use, no different from the classic Unix utilities or X.org and what not. It's much more similar to launchd used in OS X than SysVinit was, so you'd likely feel right at home.

how to contact turbotax tech support

[Anonymous Coward]

you can directly search turbotax phone number on there website

JFS and MythTV

[SIGBUS]

I've also found JFS to work best for me on a MythTV box. Aside from the file deletion issue, there's also streaming throughput during recording (especially if the storage is accessed via NFS). As much of a ZFS fan as I may be, I prefer using the best tool for the job, and MythTV is where JFS shines.

ZFS, CentOS, and DKMS

[SIGBUS]

I, for one, would absolutely love to have official ZFS modules in CentOS instead of relying on DKMS. DKMS on a CentOS box is a nightmare, because of the "weak-updates" shortcut that it likes to take (where it symlinks the modules from a previous kernel into /lib/modules/foo/weak-updates instead of, you know, actually rebuilding the modules). Sure, that's nice and fast, but it falls apart horribly once that old kernel gets deleted.

Re:ZFS, CentOS, and DKMS

[fnj]

Bingo. Hear, hear. I learned to HATE dkms and its goddamned "weak updates" with a vengeance. After intensive searching, I never found a clue anywhere as to how to beat the asinine weak update predilection out of dkms.

Alas, I have no confidence whatever that Red Hat will ever see the light on this. Believe it or not, I am now seriously looking at shitcanning it for my servers in favor of Ubuntu.

hardware upgrade

[Anonymous Coward]

I guess I better go buy a new computer then, because according the mob over on FreeNAS forums, I cant run ZFS with anything less than an Intel CPU and ECC RAM or else ZFS is not reliable.

A hackish workaround for DKMS on CentOS

[SIGBUS]

I found something a while back that seems to work:

cp /bin/true /bin/true.bak
mv /usr/sbin/weak-modules /usr/sbin/weak-modules.NONONONONO
ln -s /bin/true /usr/sbin/weak-modules

Slashdot stupidity again

[Anonymous Coward]

This is like those many yellow press "announcements". Only in the end can you get some "hint" of truth: "N.B. ext4 will still be the default file system due to the unresolved licensing conflict between Linux's GPLv2 and ZFS's CDDL.".

No comments of ZFS' problems: RAM requirements, fragmentation, not really suitable for "normal use case" SSDs. The fact that it's not really a replacement for ext4 because it is designed for multi-terabyte-highend-server-NAS. Ext4 is still the default for most cases as it is the best generic solution (specifically performance). Not because of licensing, but because of the many "not for your average Joe" limitations and Solaris toolchain requirements. The only "pro" concept of zfs is the checksum features, not its generic prowess.

This is really just another Canonical's attempt to reach the "big iron", nothing else. Lame.

FUD and TROLL

[Anonymous Coward]

What a bunch of FUD. ZFS is built up from the ground with a focus on data integrity. ZFS is the safest filesystem out there, according to several researchers. Read the research papers here, where they compare ZFS data integrity vs XFS, reiserfs, NTFS, ext4, etc - ZFS wins in every single scenario whereas the other dont:
https://en.wikipedia.org/wiki/ZFS#Data_integrity

The thing is, ZFS dont need a "fsck". First of all, "fsck" only checks metadata, it never checks the data. This means after a fsck, the data might still be corrupt. This can be proven by observing how much time fsck takes - a large 10 TB raid with fsck might complete in a few minutes. Assume each disk is capable of reading 100MB/sec. In a few minutes time you only can read, say 0.5 TB. This means all the 10TB data was never touched. Anything that claims to have examined and repaired all of 10 TB in a couple of minutes - you should realise it is not true. OTOH, ZFS "scrub" takes many hours as it touches all of 10 TB data. ZFS scrub checks metadata AND data. Another drawback of fsck, is that you can only use fsck on an unmounted pool. You need to wait. But ZFS scrub is designed to work on a live mounted pool: (scroll down to the next paragraph):
https://en.wikipedia.org/wiki/ZFS#RAID

Second, ZFS does not need "fsck" because of the ZFS COW nature. If the ZFS pool is corrupt and will not mount, you are able to roll back in time and mount the latest valid snapshot. This means you will loose the latest 30 seconds of writes, but that is often not a big problem. Every write to ZFS pool, is done in another place on the disk. The old data is never altered. So if you do 1000 edits of a file - ZFS writes 1000 new places and all the data is intact all the time. Say the latest 1000 edit corrupted the pool - then you roll back in time and mount the edit numbered 999. ZFS has automatic versioning because of COW, and you just roll back to the latest valid state. More information here on rollback:
http://www.c0t0d0s0.org/archives/6071-No,-ZFS-really-doesnt-need-a-fsck.html

Third, ZFS has been out there for ten years, and there has been no need for fsck. ZFS is enterprise, for high end storage. If the customers would have complained, ZFS would have got a fsck tool. But there has simple been no need for fsck during all these years. All problems has been possible to solve without fsck - because ZFS is designed to not use fsck.

I say TROLL and FUDer.