On 10/07/11 04:25, Chester wrote:
The problem with this is that people naturally look for a fsck tool
when something bad goes wrong. Something as important as a fsck
utility shouldn't be released (unofficially or officially) half baked.
It can irreparably destroy a filesystem which could've otherwise been
repaired with a fully functional fsck.
I think Chris is trying to prevent that from happening.
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).
This should be the fix I'm talking about (my original link to Sun site
doesn't work any more)
http://wesunsolve.net/bugid/id/6667683
You can look up the internet with something like "zfs roll back txg" or
"zfs mount old uberblock"...
I don't recall any other "I have hosed my FS" request for help after
the date this feature was implemented/provided.
Why isn't this approach dead-easy to implement with btrfs?
--
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
