Hacker News Reader

Have you actually used ZFS?

* 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.

Have you actually used ZFS?

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.

http://mail.opensolaris.org/pipermail/zfs-discuss/2008-Octob...

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.

Does btrfs solve any of these issues? And if so, how?

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)

> What a non-article. ZFS is more mature than an unmature and unstable filesystem? Really?

Keep in mind that, with one exception, ZFS is pretty much rock-solid from day one.

Also, you should really read: http://www.c0t0d0s0.org/archives/6071- No,-ZFS-really-doesnt-need-a-fsck.html

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?

More importantly, what's the problem with scrubbing instead of fsck?

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 is great, but it does break from time to time

Ah, it seems our definitions vary.

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.

> Citation needed

Maybe you should provide some citations yourself first before asking citations from others.

"Keep in mind that when ZFS was new it wasn't particularly stable either"

"ZFS isn't for the typical enthusiast/home-user"

"Nope. Never mind that ZFS assumes that harddrives works to spec, which consumer drives do not"

etc.

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.

> XFS doesn't have an fsck either

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?

Did I somehow portray that I didn't like ZFS in my post, that it wasn't mature? Or that I feel that btrfs is suitable for home users as it is today?

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.

> So, along comes btrfs that mimics the feature-set of ZFS but brings along many advantages (much thanks to it being developed much later).

Just like SystemTap mimics the feature set of DTrace and brings along many advantages due to its later development: http://dtrace.org/blogs/ahl/2007/08/02/dtrace-knockoffs/

Did you even read the article?

Sorry but I can't come up with any response other than: did you even read my post?

It actually is a decent read: Should ZFS have a fsck tool? http://www.osnews.com/story/22423/Should_ZFS_Have_a_fsck_Too...