archive mirror
 help / color / mirror / Atom feed
From: Zdenek Kabelac <>
To: LVM general discussion and development <>,
	Gionatan Danti <>
Subject: Re: [linux-lvm] Higher than expected metadata usage?
Date: Tue, 27 Mar 2018 10:30:17 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Dne 27.3.2018 v 09:44 Gionatan Danti napsal(a):
> Hi all,
> I can't wrap my head on the following reported data vs metadata usage 
> before/after a snapshot deletion.
> System is an updated CentOS 7.4 x64
> [root@ ~]# lvs
>  � LV���������� VG�������� Attr������ LSize� Pool�������� Origin� Data% Meta%  
> Move Log Cpy%Sync Convert
>  � 000-ThinPool vg_storage twi-aot---� 7.21t��������������������� 80.26 56.88
>  � Storage����� vg_storage Vwi-aot---� 7.10t 000-ThinPool�������� 76.13
>  � ZZZSnap����� vg_storage Vwi---t--k� 7.10t 000-ThinPool Storage
> As you can see, a ~80% full data pool resulted in a ~57% metadata usage
> [root@ ~]# lvremove vg_storage/ZZZSnap
>  � Logical volume "ZZZSnap" successfully removed
> [root@ ~]# lvs
>  � LV���������� VG�������� Attr������ LSize� Pool�������� Origin Data% Meta%  
> Move Log Cpy%Sync Convert
>  � 000-ThinPool vg_storage twi-aot---� 7.21t�������������������� 74.95 36.94
>  � Storage����� vg_storage Vwi-aot---� 7.10t 000-ThinPool������� 76.13
> Now data is at ~75 (5% lower), but metadata is at only ~37%: a whopping 20% 
> metadata difference for a mere 5% data freed.
> This was unexpected: I thought there was a more or less linear relation 
> between data and metadata usage as, after all, the first is about allocated 
> chunks tracked by the latter. I know that snapshots pose additional overhead 
> on metadata tracking, but based on previous tests I expected this overhead to 
> be much smaller. In this case, we are speaking about a 4X amplification for a 
> single snapshot. This is concerning because I want to *never* run out of 
> metadata space.
> If it can help, just after taking the snapshot I sparsified some file on the 
> mounted filesystem, *without* fstrimming it (so, from lvmthin standpoint, 
> nothing changed on chunk allocation).
> What am I missing? Is the "data%" field a measure of how many data chunks are 
> allocated, or does it even track "how full" are these data chunks? This would 
> benignly explain the observed discrepancy, as a partially-full data chunks can 
> be used to store other data without any new metadata allocation.
> Full LVM information:
> [root@ ~]# lvs -a -o +chunk_size
>  � LV������������������ VG�������� Attr������ LSize�� Pool Origin Data%  
> Meta%� Move Log Cpy%Sync Convert Chunk
>  � 000-ThinPool�������� vg_storage twi-aot---�� 7.21t �74.95  
> 36.94��������������������������� 4.00m
>  � [000-ThinPool_tdata] vg_storage Twi-ao----�� 7.21t 
>  ������������������������������������������� 0
>  � [000-ThinPool_tmeta] vg_storage ewi-ao---- 116.00m 
>  ������������������������������������������� 0
>  � Storage������������� vg_storage Vwi-aot---�� 7.10t 000-ThinPool 
>  �76.13������������������������������������� 0
>  � [lvol0_pmspare]����� vg_storage ewi------- 116.00m 
>  ������������������������������������������� 0


Well just for the 1st. look -  116MB for metadata for 7.21TB is *VERY* small 
size. I'm not sure what is the data 'chunk-size'  - but you will need to 
extend pool's metadata sooner or later considerably - I'd suggest at least 
2-4GB for this data size range.

Metadata itself are also allocated in some internal chunks - so releasing a 
thin-volume doesn't necessarily free space in the whole metadata chunks thus 
such chunk remains allocated and there is not a more detailed free-space 
tracking as space in chunks is shared between multiple thin volumes and is 
related to efficient storage of b-Trees...

There is no 'direct' connection between releasing space in data and metadata 
volume - so it's quite natural you will see different percentage of free space 
after thin volume removal between those two volumes.

The only problem would be if repeated operation would lead to some permanent 



  reply	other threads:[~2018-03-27  8:30 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-27  7:44 [linux-lvm] Higher than expected metadata usage? Gionatan Danti
2018-03-27  8:30 ` Zdenek Kabelac [this message]
2018-03-27  9:40   ` Gionatan Danti
2018-03-27 10:18     ` Zdenek Kabelac
2018-03-27 10:58       ` Gionatan Danti
2018-03-27 11:06         ` Gionatan Danti
2018-03-27 10:39 ` Zdenek Kabelac
2018-03-27 11:05   ` Gionatan Danti
2018-03-27 12:52     ` Zdenek Kabelac

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 \ \ \ \ \

* 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 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).