> What I would like to know instead, is WHY we need an btrfsck when ZFS does > not. Zfs also has this kind of problems especially on power failures, but > you can always mount by rolling back to a previous uberblock, showing an > earlier view of the filesystem, which would be consistent. > > It wasn't always like this with ZFS, but this "feature" has been added after > ther numerous requests of users who lost their complete filesystems after a > power failure or similar events. And there was no zfsck (there still isn't, > and it's apparently not needed).
There's a couple different categories of tool that are occasionally referred to as "fsck". Consistency checking (which we already have in the current btrfsck), data recovery (which we have a couple rough tools for, but which improved tools are desired and probably part of cmason's plans), transparent healing making the filesystem always mountable (the big selling point of both zfs and btrfs, although obviously btrfs is still immature in this regard; again, something that progress is expected on), in-place "rebuild the world" repair tools (which again I believe is part of cmason's plans), online scrubs (which we have), and so on. You'll note that zfs now has all of these tools (and took a remarkable amount of time to acquire some of them), they just never call any combination of them "zfsck". Really, zfs doesn't require fsck in exactly the same sense that ext3 doesn't: given hardware that doesn't lie to the filesystem, there's no massive "search and rescue" operation required after an otherwise unclean shutdown. That's it. And we mostly have that too, modulo the usual and expected bumps of a very young filesystem. --cwillu Warning: cwillu may cause excessive warnings. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
