archive mirror
 help / color / mirror / Atom feed
From: Zygo Blaxell <>
To: A L <>
Cc: waxhead <>,
	Btrfs BTRFS <>
Subject: Re: Switching from spacecache v1 to v2
Date: Mon, 2 Nov 2020 09:40:50 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, Nov 02, 2020 at 06:48:11AM +0100, A L wrote:
> > > And
> > > How do I make the switch properly?
> > Unmount the filesystem, mount it once with -o clear_cache,space_cache=v2.
> > It will take some time to create the tree.  After that, no mount option
> > is needed.
> > 
> > With current kernels it is not possible to upgrade while the filesystem is
> > online, i.e. to upgrade "/" you have to set rootflags in the bootloader
> > or boot from external media.  That and the long mount time to do the
> > conversion (which offends systemd's default mount timeout parameters)
> > are the two major gotchas.
> > 
> > There are some patches for future kernels that will take care of details
> > like deleting the v1 space cache inodes and other inert parts of the
> > space_cache=v1 infrastructure.  I would not bother with these
> > now, and instead let future kernels clean up automatically.
> There is also this option according to the man page of btrfs-check:
> --clear-space-cache v1|v2
>     completely wipe all free space cache of given type
>     For free space cache v1, the clear_cache kernel mount option only
> rebuilds the free space cache for block groups that are modified while the
> filesystem is mounted with that option. Thus, using this option with v1
> makes it possible to actually clear the entire free space cache.
>     For free space cache v2, the clear_cache kernel mount option destroys
> the entire free space cache. This option, with v2 provides an alternative
> method of clearing the free space cache that doesn’t require mounting the
> filesystem.
> Is there any practical difference to clearing the space cache using mount
> options? 

It's easier, because mount requires only setting flags.  It doesn't
require the additional separate step of running btrfs check.

The kernel will currently recreate parts of the v1 structures when
space_cache=v2 is used, so it will partially cancel out the work btrfs
check does.  There is a patch out there to fix that, see "btrfs: skip
space_cache v1 setup when not using it").

> For example, would a lot of old space_cache=v1 data remain on-disk
> after mounting -o clear_cache,space_cache=v2 ? 

It does, but the space used is negligible.  Future kernels will clean
it up automatically, assuming the patch set lands.

> Would that affect performance in any way?

Unused space cache is inert.  It only takes up space, and not very much
of that.

> Thanks.

  reply	other threads:[~2020-11-02 14:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-31  0:27 waxhead
2020-11-01 17:49 ` Zygo Blaxell
2020-11-02  5:48   ` A L
2020-11-02 14:40     ` Zygo Blaxell [this message]
2020-11-02 17:03   ` waxhead

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:

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

  git send-email \ \ \ \ \ \
    --subject='Re: Switching from spacecache v1 to v2' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).