All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans van Kranenburg <hans@knorrie.org>
To: dsterba@suse.cz, Chris Murphy <lists@colorremedies.com>,
	Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: space_cache=v1 and v2 at the time time?
Date: Mon, 1 Jun 2020 22:35:44 +0200	[thread overview]
Message-ID: <8883fb1b-4b5c-eae4-bbb3-babc4528399e@knorrie.org> (raw)
In-Reply-To: <20200601175252.GC18421@twin.jikos.cz>

Hi,

On 6/1/20 7:52 PM, David Sterba wrote:
> On Thu, May 28, 2020 at 11:04:07PM +0200, Hans van Kranenburg wrote:
>> Hi,
>>
>> On 5/27/20 4:12 AM, Chris Murphy wrote:
>>> What are the implications of not clearing v1 before enabling v2?
>>>
>>> From btrfs insp dump-t, I still see the v1 bitmaps present:
>>>
>>> root tree
>>> leaf 6468501504 items 42 free space 9246 generation 22 owner ROOT_TREE
>>> leaf 6468501504 flags 0x1(WRITTEN) backref revision 1
>>> ...
>>>     item 30 key (FREE_SPACE UNTYPED 22020096) itemoff 11145 itemsize 41
>>>         location key (256 INODE_ITEM 0)
>>>         cache generation 17 entries 0 bitmaps 0
>>>     item 31 key (FREE_SPACE UNTYPED 1095761920) itemoff 11104 itemsize 41
>>>         location key (257 INODE_ITEM 0)
>>>         cache generation 17 entries 0 bitmaps 0
>>> ...
>>>
>>>
>>> And later the free space tree:
>>>
>>> free space tree key (FREE_SPACE_TREE ROOT_ITEM 0)
>>> leaf 6471073792 items 39 free space 15196 generation 22 owner FREE_SPACE_TREE
>>> leaf 6471073792 flags 0x1(WRITTEN) backref revision 1
>>> fs uuid 3c464210-08c7-4cf0-b175-e4b781ebea19
>>> chunk uuid f1d18732-7c3d-401c-8637-e7d4d9c7a0b8
>>>     item 0 key (1048576 FREE_SPACE_INFO 4194304) itemoff 16275 itemsize 8
>>>         free space info extent count 2 flags 0
>>>     item 1 key (1048576 FREE_SPACE_EXTENT 16384) itemoff 16275 itemsize 0
>>>         free space extent
>>>     item 2 key (1081344 FREE_SPACE_EXTENT 4161536) itemoff 16275 itemsize 0
>>>         free space extent
>>> ...
>>>
>>> I was surprised there's no warning when I use space_cache=v2 without
>>> first clearing v1.
>>
>> It's just sitting there, occupying some space, doing nothing.
> 
> Hm that's not ideal, right? There's support in btrfs check,
> "btrfs check --clear-space-cache v1", but it needs unmounted filesystem.
> I don't remember if that was discussed when v2 was introduced, but it
> seems strange. As we want to make v2 default soon, the conversion should
> work without such surprises.

I guess the most straightforward thing to do would be to execute a copy
of this remove space cache v1 code before creating the v2 tree when
mounting first time with v2 enabled.

K

      reply	other threads:[~2020-06-01 20:35 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-27  2:12 space_cache=v1 and v2 at the time time? Chris Murphy
2020-05-28 21:04 ` Hans van Kranenburg
2020-06-01 17:52   ` David Sterba
2020-06-01 20:35     ` Hans van Kranenburg [this message]

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=8883fb1b-4b5c-eae4-bbb3-babc4528399e@knorrie.org \
    --to=hans@knorrie.org \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@colorremedies.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.