From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx1.redhat.com (ext-mx06.extmail.prod.ext.phx2.redhat.com [10.5.110.30]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CD20660468 for ; Sun, 17 Sep 2017 06:31:41 +0000 (UTC) Received: from smtp1.signet.nl (smtp1.signet.nl [83.96.147.43]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 94B3D356C0 for ; Sun, 17 Sep 2017 06:31:38 +0000 (UTC) Received: from webmail.dds.nl (app2.dds.nl [81.21.136.118]) by smtp1.signet.nl (Postfix) with ESMTP id 1AEDD67AD1 for ; Sun, 17 Sep 2017 08:31:37 +0200 (CEST) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Date: Sun, 17 Sep 2017 08:31:36 +0200 From: Xen In-Reply-To: <458d105938796d90f4e426bc458e8cc4@xenhideout.nl> References: <76b114ca-404b-d7e5-8f59-26336acaadcf@assyoma.it> <0c6c96790329aec2e75505eaf544bade@assyoma.it> <8fee43a1-dd57-f0a5-c9de-8bf74f16afb0@gmail.com> <7d0d218c420d7c687d1a17342da5ca00@xenhideout.nl> <6e9535b6-218c-3f66-2048-88e1fcd21329@redhat.com> <2cea88d3e483b3db671cc8dd446d66d0@xenhideout.nl> <9115414464834226be029dacb9b82236@xenhideout.nl> <50f67268-a44e-7cb7-f20a-7b7e15afde3a@redhat.com> <595ff1d4-3277-ca5e-a18e-d62eaaf0b1a0@redhat.com> <9aa2d67c38af3e4042bd3f37559b799d@xenhideout.nl> <2d1025d7784ab44cbc03cfe7f6778599@xenhideout.nl> <58f99204-d978-3f6a-9db8-b7122b30575e@redhat.com> <458d105938796d90f4e426bc458e8cc4@xenhideout.nl> Message-ID: Subject: Re: [linux-lvm] Reserve space for specific thin logical volumes Reply-To: LVM general discussion and development List-Id: LVM general discussion and development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , List-Id: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: linux-lvm@redhat.com Xen schreef op 17-09-2017 0:33: > But if it's not active, can it still 'trace' another volume? Ie. it > has to get updated if it is really a snapshot of something right. > > If it doesn't get updated (and not written to) then it also does not > allocate new extents. Oh now I get what you mean. If it's not active it can also in that sense not reserve any extents for itself. So the calculations I proposed way below require at least 2 numbers for each 'critical' volume to be present in the kernel. Which is the unallocated virtual size and the reserved space. So even if they're not active they would need to provide this information somehow. Of course the information also doesn't change if it's not active, so it would just be 2 static numbers. But then what happens if you change the reserved space etc... In any case that sorta thing would indeed be required... (For an in-kernel thing...) (Also any snapshot of a critical volume would not in itself become a critical volume...) (But you're saying that "thin snapshot" is not a kernel concept...)