What a non-article. ZFS is more mature than an unmature and unstable filesystem? Really?
The article is also full of irrelevant details and downright faulty statements.
ZFS is more stable. Yeah, if it wasn't that'd be really bad. Keep in mind that when ZFS was new it wasn't particularly stable either, despite the arguments put forward - a file system must mature with time.
ZFS isn't for the typical enthusiast/home-user. It can't be more apparent than the fact that ZFS dosesn't have a fsck-tool, why doesn't ZFS need a fsck-tool? Because every time you'd need it you just restore your backups from tape instead ( Should ZFS have a fsck tool? http://www.osnews.com/story/22423/Should_ZFS_Have_a_fsck_Too... )
You can yank the power cord of your machine -- you will never lose a single byte of anything committed to the disk. ZFS is always consistent on disk, and never trusts any faulty data (that might have become damaged because of hardware issues).
Nope. Never mind that ZFS assumes that harddrives works to spec, which consumer drives do not (keep in mind that ZFS is designed to be able to run on consumer drives). Meaning that you can not yank the power cord to your machine (if you care about your data).
ZFS truly is awesome, it makes all other easily available linux filesystems look really, really, really poor. Which truly sucks, if you use linux (honestly, I haven't checked the linux alternatives for ZFS but I have a really hard time believing that anyone should trust such an untested solution, just use a stable linux filesystem and wait, patiently, for btrfs).
So, along comes btrfs that mimics the feature-set of ZFS but brings along many advantages (much thanks to it being developed much later). And btrfs has a different target group. Btrfs is much better adapted for home use (it even has a fsck-tool!).
But, btrfs isn't stable (and it shouldn't be trusted in the near future)... And I just can't fathom how you can write such an comparison between btrfs and ZFS today, it just doesn't make sense.
When btrfs is stable and mature things should get interesting.
* ZFS doesn't include fsck because it doesn't make sense when your FS is guaranteed to be consistent. fsck is for when writes go bad because the window is there for that to happen.
Your claim is like saying a an electric car doesn't make sense because how is the consumer would be confused that it doesn't have a gas tank.
You don't backup ZFS filesystems to tape. I don't know of anyone doing that. It's a weird statement. If you want worst-case-scenario backups, you replicate.
Of course with auto-snapshots setup, and the basic inability of ZFS to become corrupted (IME, never had an issue with v28), you wouldn't be more or less likely to do that as a consumer than you would be to buy an external HDD for your Mac and use TimeMachine.
The only reason it isn't for the typical user is that the typical user doesn't run Solaris or FreeBSD.
* "Never mind that ZFS assumes that hard drives works to spec"
I don't know where you got that. It's actually just the opposite. It checksums everything and includes several facilities to catch early corruption and address it before you ever lose data.
On top of that most ZFS arrays I've worked with are standard 1TB to 2TB SATA systems. Nothing particularly special about the drives. Early on that was one of the big selling points of ZFS. That it was built for commodity hardware.
I personally have pulled the power plug on 24 to 48 disk arrays, literally hundreds of times while under heavy load and have never once lost data.
Not that I haven't run into other issues a few years ago, but data loss due to sudden power loss wasn't ever one of them.
It's almost comically easy to lose data (again, IME) on an ext3/4 system under the same scenarios. That's comparing zero ZFS losses to maybe a dozen of ext losses over the past 3 years.
In the lab, yes. Oracle killed my plans of adopting it.
I don't know where you got that. It's actually just the opposite. It checksums everything and includes several facilities to catch early corruption and address it before you ever lose data.
Yes, that is the idea. But it is based, as the article mentions, in ZFS uses atomic writes and barriers. So, how can you guarantee that? ZFS does it by writing data to the drive and making sure that the data actually has been written, how can ZFS be sure of that? It asks the drive. The problem is that consumer drives often lie and report that data has been written when it is currently only residing in the cache. And that's a great recipe for data corruption.
ZFS checksums are beyond awesome, but they don't combat this.
Jeff Bonwick explains it better than I could:
As you note,
some disks flat-out lie: you issue the synchronize-cache command,
they say "got it, boss", yet the data is still not on stable storage.
Why do they do this? Because "it performs better". Well, duh --
you can make stuff really fast if it doesn't have to be correct.
Before I explain how ZFS can fix this, I need to get something off my
chest: people who knowingly make such disks should be in federal prison.
It is fraud to win benchmarks this way.
I personally have pulled the power plug on 24 to 48 disk arrays, literally hundreds of times while under heavy load and have never once lost data.
I hope you don't use consumer drives or really do your research.
The same problem has bitten people running ZFS in a virtual machine, such as vmware ESX, that had similar problems where they couldn't trust the drive to behave as it was told, and corruption followed. Which kind of sucks when you don't have any means of repairing the damage.
Also, the replies I've gotten seems to imply that I have something against ZFS. I love ZFS but I see more potential in btrfs - but btrfs is many years away from even being worth considering an opponent to ZFS so that is kind of moot. All I want is a decent copy-on-write linux file system with cheap snapshots (and preferably good encryption support).
Recent versions of ZFS have solved the problem of drives ignoring the synchronize cache command.
Now ZFS always keeps around the latest 3 transaction groups, regardless if any data on any one of those transaction groups has been freed/updated already.
So if the last transaction group gets corrupted during an abrupt power down, it can always go back to the latest consistent one.
By spending effort and providing tools for data recovery and file system repair (since btrfs is neither stable nor mature these leave much to be desired but the effort is clear and it is quite a contrast compared to ZFS).
The ZFS stand on this is that nothing can go wrong. If something does go wrong, which by the way is impossible, you better have your backups ready because you are on your own.
A good fact to keep in mind is that ZFS is meant to run on adequate hardware. ECC Ram (ZFS is more prone to corruption from random memory errors than most other filesystems, it assumes your ram is reliable), drives that don't lie about writes, adequate CPU overhead. it was designed to go BIG - and when you go big, these things are a given. If you skimp on any of these, it doesn't look as good - but small-scale wasn't it's target market.
(And I'm not saying nobody should use ZFS on a small scale... but it was designed with some specific assumptions that are perfectly fair given it's target market)
If you are runninga a system at a scale where ZFS makes sense and not making backups of critical data, your operations process is fundamentally broken anyway. ZFS doesn't change the need for backups one bit (and it brings to the table some novel ways of doing offsite snapshots and whatnot, to boot)
Keep in mind that, with one exception, ZFS is pretty much rock-solid from day one.
Citation needed.
And that article doesn't really address any of the problems that the osnews article brings up, it just tries to sidestep the issue by more or less saying that the same fsck tool that ext uses won't work on ZFS. Great.
ZFS was released in 2005, and appeared in Solaris 10 in 2006. Close enough?
Followed by that was people having issues with data corruption... ZFS is great, but it does break from time to time (whether it is better than other file systems is subjective when you consider the options of restoring it). Low failure rate is, for many, a weak comfort when data is irrecoverable.
More importantly, what's the problem with scrubbing instead of fsck?
Scrubbing repairs data, not broken file systems. Scrubbing is of course great but it isn't the answer for everything.
ZFS has had problems, but all production filesystems have. From a strict standpoint, what the original author wrote about bugs is wrong, but from a practical standpoint I don't think it matters. ZFS has been as solid as any other production filesystem from the beginning -- which is to say that any production filesystem might one day rear up and bite you. It's just the nature of our profession.
That's just my opinion though. :)
Scrubbing repairs data, not broken file systems.
That depends what's broken. ZFS has ditto blocks (multiple copies of the same block) going up the tree; roughly speaking, the higher up you are, the more there are. The tree and metadata has more protection than the data itself.
If, say, all the ditto blocks and all the mirrors are corrupt, reconstructing that is going to be hard. I think a case needs to be made that an fsck tool would do a better job repairing than scrubbing, which is non-obvious to me.
Keep in mind that, with one exception, ZFS is pretty much rock-solid from day one.
When we used it in production about 5 years ago it was not so rock-solid. We had to bring in Sun-Support and went through some nasty downtimes for lengthy resilvering.
As an enthusiast/home-user I use ZFS, and it has saved my data in situations where no linux filesystem I've tried would. XFS doesn't have an fsck either; more to the point, more does btrfs, so you can't really give that as a reason why btrfs is more suitable for home users.
Oops, actually back in 1995 when XFS was made available, it hadn't any fsck because it supposedly didn't need it. However, they finally made "xfs_repair" available one year later, which while not being called "fsck" proper, still is the same thing.
BTW one thing that xfs_repair did for me was getting back most of the data from an xlv array with a failed drive. Isn't it awesome?
You said "ZFS isn't for the typical enthusiast/home-user". I don't think that's true (or rather, while there are problems with using ZFS as such a user, the problems with all the alternatives are worse); I would advise such users to use ZFS.
The article is also full of irrelevant details and downright faulty statements.
ZFS is more stable. Yeah, if it wasn't that'd be really bad. Keep in mind that when ZFS was new it wasn't particularly stable either, despite the arguments put forward - a file system must mature with time.
ZFS isn't for the typical enthusiast/home-user. It can't be more apparent than the fact that ZFS dosesn't have a fsck-tool, why doesn't ZFS need a fsck-tool? Because every time you'd need it you just restore your backups from tape instead ( Should ZFS have a fsck tool? http://www.osnews.com/story/22423/Should_ZFS_Have_a_fsck_Too... )
You can yank the power cord of your machine -- you will never lose a single byte of anything committed to the disk. ZFS is always consistent on disk, and never trusts any faulty data (that might have become damaged because of hardware issues).
Nope. Never mind that ZFS assumes that harddrives works to spec, which consumer drives do not (keep in mind that ZFS is designed to be able to run on consumer drives). Meaning that you can not yank the power cord to your machine (if you care about your data).
ZFS truly is awesome, it makes all other easily available linux filesystems look really, really, really poor. Which truly sucks, if you use linux (honestly, I haven't checked the linux alternatives for ZFS but I have a really hard time believing that anyone should trust such an untested solution, just use a stable linux filesystem and wait, patiently, for btrfs).
So, along comes btrfs that mimics the feature-set of ZFS but brings along many advantages (much thanks to it being developed much later). And btrfs has a different target group. Btrfs is much better adapted for home use (it even has a fsck-tool!).
But, btrfs isn't stable (and it shouldn't be trusted in the near future)... And I just can't fathom how you can write such an comparison between btrfs and ZFS today, it just doesn't make sense.
When btrfs is stable and mature things should get interesting.