Re: Question: How can I recover this partition? (unable to find logical $hugenum len 4096)

From: Chris Murphy <lists@colorremedies.com>
To: Zach Brown <zab@redhat.com>
Cc: Hugo Mills <hugo@carfax.org.uk>, Nick Lee <email@nickle.es>,
	linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Question: How can I recover this partition? (unable to find logical $hugenum len 4096)
Date: Thu, 29 Aug 2013 13:37:51 -0600	[thread overview]
Message-ID: <528DF163-08F5-412D-8351-ACC853AC418D@colorremedies.com> (raw)
In-Reply-To: <20130829173519.GN26818@lenny.home.zabbo.net>

On Aug 29, 2013, at 11:35 AM, Zach Brown <zab@redhat.com> wrote:

>>   If those fail, then look in dmesg for errors relating to the log
>> tree -- if that's corrupt and can't be read (or causes a crash), use
>> btrfs-zero-log.
> 
> In a bit of a tangent:
> 
> btrfs-zero-log throws away data that fsync/sync could have previously
> claimed was stable on disk.
> 
> Given how often this is thrown around as a solution to a broken
> partition, should the tool jump up and down and make it clear that it's
> about to roll the file system back?  This seems like relevant
> information.
> 
> Right now, as far as I can tell, it's completely undocumented and
> silent.

Yes, I think it helps remove some burden on the list answering questions about a tool that doesn't have any documentation, to have a warning.

How much longer will btrfs-zero-log be needed? If whatever it's doing isn't obviated by future improvements to btrfsck, and this sort of big hammer approach is still needed in some worse case scenarios, then it probably hurts no one to flag the user with essentially how you described it. I think documentation is a greater burden to create, and less likely to be consulted.

"Proceeding will roll back the file system to a previous state, and may cause the loss of successfully written data. Proceed? (Y/N)"

Alternative language could include a suggestion or reminder of what should be tried before proceeding, if applicable.

Chris Murphy