Interesting article at Ars Technica: ZFS and BTRFS

X

xy16644

I have just read an interesting article at Ars Technica:

Bitrot and atomic COWs: Inside “next-gen” filesystems

Although I have heard of BTRFS I don't/didn't know much about it since I only use ZFS. Some of the features BTRFS has are:

  • File-level cloning
  • Online balancing
  • File-level/Directory-level compression

Will ZFS ever get the above features :) I'm still sticking with ZFS!

I'd be interested to hear what the forum thinks about BTRFS vs ZFS. I liked his example of flipped bits with his kid's photo. Very cool way of demonstrating a cutting edge file system!
 
When I read the article I couldn't help pick up some prejudice. At least that's how it looked to me.

For example; I don't see the advantage of file level cloning. The author claims that it's huge when you want to copy a file out of a snapshot; ZFS performs an actual copy but BTRFS can clone the file so that you can get it out in an instant. All fine and well, but snapshots are usually not kept around forever. So I can't help wonder what would happen when the original snapshot got destroyed when you still have cloned files around while treating them as if they were actually restored files (which they weren't). I'll take a real restoration (and making the restored file part of the filesystem once more) over such a "hack" any time of the week. Maybe I don't grasp the concept, but I don't see any advantage. Perhaps apart from initially saving time. But what good is that if you'll have to eventually copy things out anyway?

And the rest of the new features weren't really interesting to me. For example; being able to apply compression on a per-directory basis sounds nice. But given the fact that it's very easy to create a filesystem (on ZFS anyway) I also see little advantages there. In fact; I can't help wonder if this wouldn't become an administrative issue; how are you going to recall which directories got compressed and which weren't apart from documenting them? Of course, this can also simply be my prejudice showing ;)

Anyway, I won't be switching any day soon :)

Edit: s/they we're/they were/
 
xy16644 said:
  • File-level cloning
  • Online balancing
  • File-level/Directory-level compression
Click to expand...

Compression, didn't we just get lz4, which kinda kind of makes you don't have to worry what files are compressible and what files are not? "The performance on incompressible data is a large improvement, this comes from an 'early abort' feature, if ZFS detects that the compression savings is less than 12.5% then compression is aborted and the block is written uncompressed" (got it from here: http://freebsdnow.blogspot.nl/2013/07/f ... s-lz4.html)

The 'online balancing' feature seems nice, but I'll bet that when such a feature is implemented in ZFS nobody will want to run less than RAIDZ3, making it a bit too late. I think? Not sure about this though.
 
I think new versions of ZFS have the compression feature so that is covered. I do like the idea of the file "clone" feature. I'd like to see ZFS gain that ability. For small files it won't matter, but realyl large file restores would benefit.

As an above poster said, parts of the article do seem to favour BTRFS, which makes a bit of sense since it appears as though the author is running on Linux and the Linux community tends to prefer BTRFS. The author did point out though, to his credit, that BTRFS is still experimental and ZFS is stable. In my mind that balances things out a bit. While BTRFS has some great features, it isn't yet mature enough for me to use in production.
 
We'll see.

What I can see so far, is that ZFS is mature production-quality file system , while BTRFS still remains an ambitious enough yet "still experimental" product.

What about the ambitions BTRFS has, the features it ambitiously aims at including in some more or less effective way?
Well, we know having ambitions is one thing, being able to perform up to them -- that's another one. There are always limits as to how many features can be incorporated, say, into a file system, without it growing too huge a piece of software, resource hungry etc. Unless there should be some ground-breaking invention, apart from routine code-writing, one cannot expect miracles, really.
Then, once having actually incorporated all the features it aims at and becoming stable at that, how much (if any) better will BTRFS be compared to ZFS?
For that I have a good example of EXT3 vs EXT4: EXT3 is by far the best for an average user's needs, it's quicker and offers good file recovery possibility. So there was much fanfare over the appearance of EXT4, but I found that fs to be rather a disappointment and had to switch back to EXT3.

And finally, BTRFS has to do with Linux, and that's what makes me skeptical about it. For the same reasons that I recently switched from Linux to FreeBSD after being Linux fan for more than a decade: FreeBSD is steadily growing better (more desktop-friendly, among other things) while Linux growing more Windows-like. I'm afraid, its tendency of trying to include all things shows up in BTRFS as well. So I don't believe all those blogs painting miracles about BTRFS, not until I've heard about its production usage.

And finally, regarding financial support neither of the two has reasons to complain: BTRFS has Facebook for testing and support, then ZFS has OpenZFS project to support it. So we'll see, we'll see.
 
One thing that series of articles didn't cover, and that matter a hell of a lot to anyone actually using it in real life, are the management tools.

zpool and zfs are all you need for managing ZFS pools. And the commands are simple, easy-to-read, English words, and the commands are almost proper English sentences.

The management tools for btrfs (while improving) are still light-years behind those of ZFS. Just look at "btrfs df fi". What does that mean? The documentation for the commands also lag behind. And the commands have changed several times over the past couple of years, littering the mailing lists with "don't do it that way, this is the way now" posts.

btrfs has come a long way over the past few years, but it never seems to get any closer to "production-ready", and the advice always comes down to "wait until the next release of the Linux kernel, things will be so much better then".
 
More like
Code: 
10: print "wait until the next release of the Linux kernel, things will be so much better then"
20: goto 10

And, BTW, happy birthday BASIC.
 
You must log in or register to reply here.
Back
Top