* space_cache=v1 and v2 at the time time?
@ 2020-05-27 2:12 Chris Murphy
2020-05-28 21:04 ` Hans van Kranenburg
0 siblings, 1 reply; 4+ messages in thread
From: Chris Murphy @ 2020-05-27 2:12 UTC (permalink / raw)
To: Btrfs BTRFS
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.
--
Chris Murphy
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: space_cache=v1 and v2 at the time time?
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
0 siblings, 1 reply; 4+ messages in thread
From: Hans van Kranenburg @ 2020-05-28 21:04 UTC (permalink / raw)
To: Chris Murphy, Btrfs BTRFS
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.
Hans
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: space_cache=v1 and v2 at the time time?
2020-05-28 21:04 ` Hans van Kranenburg
@ 2020-06-01 17:52 ` David Sterba
2020-06-01 20:35 ` Hans van Kranenburg
0 siblings, 1 reply; 4+ messages in thread
From: David Sterba @ 2020-06-01 17:52 UTC (permalink / raw)
To: Hans van Kranenburg; +Cc: Chris Murphy, Btrfs BTRFS
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: space_cache=v1 and v2 at the time time?
2020-06-01 17:52 ` David Sterba
@ 2020-06-01 20:35 ` Hans van Kranenburg
0 siblings, 0 replies; 4+ messages in thread
From: Hans van Kranenburg @ 2020-06-01 20:35 UTC (permalink / raw)
To: dsterba, Chris Murphy, Btrfs BTRFS
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-06-01 20:35 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 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).