From mboxrd@z Thu Jan 1 00:00:00 1970 From: Asdo Subject: Re: Honest timeline for btrfsck Date: Fri, 07 Oct 2011 21:10:33 +0200 Message-ID: <4E8F4EA9.4090108@shiftmail.org> References: <4E5FE9FC.9040705@cchtml.com> <20110901203442.GA17928@carfax.org.uk> <201109101209.40759.Martin@lichtvoll.de> <20111005061628.GA3702@shiny.elevennetworks.com> <20111005145843.GA4770@shiny.elevennetworks.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Cc: Jeff Putney , linux-btrfs To: Chester , Chris Mason Return-path: In-reply-to: List-ID: 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?