All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Murphy <lists@colorremedies.com>
To: Larkin Lowrey <llowrey@nuclearwinter.com>
Cc: "Hans van Kranenburg" <Hans.van.Kranenburg@mendix.com>,
	"Chris Murphy" <lists@colorremedies.com>,
	"Holger Hoffstätte" <holger@applied-asynchrony.com>,
	"Qu Wenruo" <quwenruo.btrfs@gmx.com>,
	"Btrfs BTRFS" <linux-btrfs@vger.kernel.org>
Subject: Re: Scrub aborts due to corrupt leaf
Date: Wed, 10 Oct 2018 20:51:01 -0600	[thread overview]
Message-ID: <CAJCQCtSbLkpYnwEO05D5R2oXVznJ3KwBxjyfBDnM4PaGwSXUhg@mail.gmail.com> (raw)
In-Reply-To: <9e6b268b-b545-bad1-f33a-b29ea1af7db0@nuclearwinter.com>

On Wed, Oct 10, 2018 at 8:12 PM, Larkin Lowrey
<llowrey@nuclearwinter.com> wrote:
> On 10/10/2018 7:55 PM, Hans van Kranenburg wrote:
>>
>> On 10/10/2018 07:44 PM, Chris Murphy wrote:
>>>
>>>
>>> I'm pretty sure you have to umount, and then clear the space_cache
>>> with 'btrfs check --clear-space-cache=v1' and then do a one time mount
>>> with -o space_cache=v2.
>>
>> The --clear-space-cache=v1 is optional, but recommended, if you are
>> someone who do not likes to keep accumulated cruft.
>>
>> The v2 mount (rw mount!!!) does not remove the v1 cache. If you just
>> mount with v2, the v1 data keeps being there, doing nothing any more.
>
>
> Theoretically I have the v2 space_cache enabled. After a clean umount...
>
> # mount -onospace_cache /backups
> [  391.243175] BTRFS info (device dm-3): disabling free space tree
> [  391.249213] BTRFS error (device dm-3): cannot disable free space tree
> [  391.255884] BTRFS error (device dm-3): open_ctree failed

"free space tree" is the v2 space cache, and once enabled it cannot be
disabled with nospace_cache mount option. If you want to run with
nospace_cache you'll need to clear it.


>
> # mount -ospace_cache=v1 /backups/
> mount: /backups: wrong fs type, bad option, bad superblock on
> /dev/mapper/Cached-Backups, missing codepage or helper program, or other
> error
> [  983.501874] BTRFS info (device dm-3): enabling disk space caching
> [  983.508052] BTRFS error (device dm-3): cannot disable free space tree
> [  983.514633] BTRFS error (device dm-3): open_ctree failed

You cannot go back and forth between v1 and v2. Once v2 is enabled,
it's always used regardless of any mount option. You'll need to use
btrfs check to clear the v2 cache if you want to use v1 cache.


>
> # btrfs check --clear-space-cache v1 /dev/Cached/Backups
> Opening filesystem to check...
> couldn't open RDWR because of unsupported option features (3).
> ERROR: cannot open file system

You're missing the '=' symbol for the clear option, that's why it fails.




-- 
Chris Murphy

  reply	other threads:[~2018-10-11  2:51 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-26 20:45 Scrub aborts due to corrupt leaf Larkin Lowrey
2018-08-27  0:16 ` Qu Wenruo
2018-08-27  2:32   ` Larkin Lowrey
2018-08-27  4:46     ` Qu Wenruo
2018-08-28  2:12       ` Larkin Lowrey
2018-08-28  3:29         ` Chris Murphy
2018-08-28 13:29         ` Larkin Lowrey
2018-08-28 13:42           ` Qu Wenruo
2018-08-28 13:56             ` Chris Murphy
2018-08-29  1:27               ` Qu Wenruo
2018-08-29  5:32               ` Qu Wenruo
2018-09-11 15:23                 ` Larkin Lowrey
2018-10-10 15:44                   ` Larkin Lowrey
2018-10-10 16:04                     ` Holger Hoffstätte
2018-10-10 17:25                       ` Larkin Lowrey
2018-10-10 18:20                         ` Holger Hoffstätte
2018-10-10 18:31                           ` Larkin Lowrey
2018-10-10 19:53                             ` Chris Murphy
2018-10-10 23:43                         ` Qu Wenruo
2018-10-10 17:44                       ` Chris Murphy
2018-10-10 18:25                         ` Holger Hoffstätte
2018-10-10 23:55                         ` Hans van Kranenburg
2018-10-11  2:12                           ` Larkin Lowrey
2018-10-11  2:51                             ` Chris Murphy [this message]
2018-10-11  3:07                               ` Larkin Lowrey
2018-10-11  4:00                                 ` Chris Murphy
2018-10-11  4:15                                   ` Chris Murphy
2018-12-31 15:52                                     ` Larkin Lowrey
2019-01-01  0:12                                       ` Qu Wenruo
2019-01-01  2:38                                         ` Larkin Lowrey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJCQCtSbLkpYnwEO05D5R2oXVznJ3KwBxjyfBDnM4PaGwSXUhg@mail.gmail.com \
    --to=lists@colorremedies.com \
    --cc=Hans.van.Kranenburg@mendix.com \
    --cc=holger@applied-asynchrony.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=llowrey@nuclearwinter.com \
    --cc=quwenruo.btrfs@gmx.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.