From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [10.40.200.37] (ovpn-200-37.brq.redhat.com [10.40.200.37]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8EJfFS6004174 for ; Mon, 14 Sep 2015 15:41:16 -0400 References: <55F70C58.5010205@windriver.com> <55F71650.7070907@redhat.com> <55F71D24.9010903@windriver.com> From: Zdenek Kabelac Message-ID: <55F722DB.9040503@redhat.com> Date: Mon, 14 Sep 2015 21:41:15 +0200 MIME-Version: 1.0 In-Reply-To: <55F71D24.9010903@windriver.com> Content-Transfer-Encoding: 7bit Subject: Re: [linux-lvm] Any way to speed up activation of volumes with snapshots? 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: LVM general discussion and development Dne 14.9.2015 v 21:16 Chris Friesen napsal(a): > On 09/14/2015 12:47 PM, Zdenek Kabelac wrote: >> Dne 14.9.2015 v 20:05 Chris Friesen napsal(a): >>> Hi, >>> >>> I'm running a 3.10 kernel with LVM 2.02.95. >>> >>> I'm running into a problem where activating snapshots can take quite a long >>> time, roughly one minute per 25GB of delta between the snapshot and the origin >>> volume. (See below for my test procedure.) >>> >>> I realize that my kernel/LVM aren't exactly bleeding edge, and I wondering >>> whether more recent versions have done anything to speed up the activation >>> process (like maybe making it more lazy-loaded rather than reading in a bunch >>> of data up-front). >>> >>> If anyone is aware of such improvements, I'd appreciate it if you could point >>> me at the appropriate changes. >> >> Hi >> >> There is NO way to accelerate your existing setup, other then placing delta on >> SSD - the format of snapshot was meant to be used 'temporarily' - i.e. until >> you >> take backup of LV - but not for long-term multi-gigabyte case. >> >> This is major mis-use of this 'snapshot' feature - which repeats over and >> over... >> >> If you want to use long-living snapshots - you need to use thin-provisioning, > > Thanks for the quick response. > > Presumably we would still have multi-GB of delta between the original volume > and the snapshot, so what would make the activation of a thin-provisioned > snapshot faster? Is the metadata stored differently? Yes - metadata are on separate device(LV) and are using b-trees. So now you could i.e. chain snap-of-snap-of-snap... Also snaps do not need to be active with origin and many other goodies. Drawbacks - all data have to be in same pool and share same space, so you can't run 'just' 'snapshot' out-of-space - whole pool is out-of-space. Also min chunk size is 64K (instead of 4K for old-snap) Anyway - try and play and see what performs better and suit your needs. Zdenek