Hacker News new | comments | show | ask | jobs | submit login

One of the few feature btrs has which ZFS hasn't.



At this point, I don't think it's fair to imply that btrfs is lagging behind ZFS. Yes, there are quite a few things that ZFS does better than btrfs, but btrfs isn't following in ZFS's footsteps and has some killer features that ZFS will never have, like on-the-fly changing between RAID modes and resizing arrays in either direction.


Btrfs has a broken by design on disk format. Btrfs went with self describing checksums inside blocks instead of a Merkle-DAG with a round robin root. In doing so they ignored existing research at the start of the btrfs project and the only fix is to change the on disk format to add the children's checkums to the parent nodes.


That doesn't sound "broken by design" to me, just less thoroughly safeguarded than ZFS but still more than almost any other filesystem. It's completely consistent with my claim that btrfs isn't trying to follow exactly in the footsteps of ZFS. (And it's not like Merkle trees don't have any tradeoffs.)


ZFS would need block pointer rewrites to implement those features, right? I don't think ZFS developers are opposed to that, but progress is just stalled. So I think "will never have" is a bit strongly worded.


https://www.youtube.com/watch?v=G2vIdPmsnTI#t=44m53s

The above video is an explanation of a bunch of the barriers to implementing block pointer rewrites. The conclusion is that it would make the code a lot more complicated and break a lot of the layering, and probably make addition of other new features a lot harder. Even a standalone offline rewriting tool wouldn't necessarily be accepted into the OpenZFS codebase because of the maintenance burden. Their advice is that if you think you need that feature to solve a particular problem, you should be looking for a workaround to solve that problem without requiring the huge block pointer rewrite project (which nobody's working on), even if the workarounds have a significant and permanent performance impact.

When you take into account how long the feature's been in demand and been on the roadmaps under "eventually", it's clearly not going to happen anytime soon and won't happen without a major change to how ZFS development is being done. It's not definitely impossible, but it's perpetually several years away from happening. With btrfs already having it's equivalent to that feature and stealing an ever-growing slice of the users who need that feature, it's probably never going to happen for ZFS.


A feature similar to this was discussed at the OpenZFS Developers Summit earlier this month

http://open-zfs.org/w/images/7/71/Fast_File_Cloning-Pavel_Za...




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: